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