[swift-dev] Profiling ARC
jray319 at gmail.com
Mon Feb 20 16:24:19 CST 2017
You are right that regex has many ARC operations from libFoundation.
Another outlier in terms of the number of ARC operations is binary-tree.
In this case, ARC operations are from the user code, and the optimizer
couldn't make much difference.
Other than these two, the optimizer seems working pretty well in removing
On Fri, Feb 17, 2017 at 1:34 PM David P Grove <groved at us.ibm.com> wrote:
> swift-dev-bounces at swift.org wrote on 02/16/2017 09:48:28 PM:
> > I was curious about the overhead of ARC and started profiling some
> > benchmarks found in the Computer Language Benchmark Game (http://
> > benchmarksgame.alioth.debian.org/u64q/measurements.php?lang=swift).
> > So far, it seems that ARC sequence optimization is surprisingly good
> > and most benchmarks don't have to perform ARC operations as often as
> > I expected. I have some questions regarding this finding.
> > I compiled all benchmarks with "-O -wmo" flags and counted the
> > number of calls to ARC runtime (e.g., swift_rt_swift_retain) using Pin.
> > 1. Reference counting is considered to have high overhead due to
> > frequent counting operations which also have to be atomic. At least
> > for the benchmarks I tested, it is not the case and there is almost
> > no overhead. Is it expected behavior? Or is it because the
> > benchmarks are too simple (they are all single-file programs)? How
> > do you estimate the overhead of ARC would be?
> 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
> *(See attached file: regex-dna.svg)*
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-dev