<html><body><p><tt>swift-dev-bounces@swift.org wrote on 02/16/2017 09:48:28 PM:</tt><br><tt>> <br>> I was curious about the overhead of ARC and started profiling some <br>> benchmarks found in the Computer Language Benchmark Game (http://<br>> benchmarksgame.alioth.debian.org/u64q/measurements.php?lang=swift). <br>> So far, it seems that ARC sequence optimization is surprisingly good<br>> and most benchmarks don't have to perform ARC operations as often as<br>> I expected. I have some questions regarding this finding.</tt><br><tt>> <br>> I compiled all benchmarks with "-O -wmo" flags and counted the <br>> number of calls to ARC runtime (e.g., swift_rt_swift_retain) using Pin.</tt><br><tt>> <br>> 1. Reference counting is considered to have high overhead due to <br>> frequent counting operations which also have to be atomic. At least<br>> for the benchmarks I tested, it is not the case and there is almost <br>> no overhead. Is it expected behavior? Or is it because the <br>> benchmarks are too simple (they are all single-file programs)? How <br>> do you estimate the overhead of ARC would be?</tt><br><tt>> <br></tt><br><tt>hmm, I wonder if your method of profiling is really finding all the ARC operations. The Swift version of regex-dna is about 25x slower than the Java version (on Linux). I looked at some prof profiles about a month ago and at the time roughly 80% of all execution samples were attributed to swift_retain/swift_release operations coming from CoreFoundation's regex implementation. </tt><br><br><tt>--dave</tt><br><br><i>(See attached file: regex-dna.svg)</i><BR>
</body></html>