[swift-dev] Profiling ARC

[David P Grove]

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
implementation.

--dave

(See attached file: regex-dna.svg)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20170217/f1de66db/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: regex-dna.svg
Type: application/octet-stream
Size: 51071 bytes
Desc: not available
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20170217/f1de66db/attachment.obj>