Re:Apple is rewriting Foundation in Swift
by olliej on Monday May 22, 2023 @01:31AM
(#36027781)
Swift's refcounting is atomic (as is objc's). As long as you're not under contention most benchmarks I've seen show negligible overhead (from the addition of atomicity, the refcount overhead is still there) for uncontended access. But IME if you do have many threads walking the same data structure you end up spending stupid amounts of time fighting the refcounting. This applies even if the data structure is immutable and has guaranteed lifetime as swift's type system doesn't seem to allow that to be expressed, and as a result it seems to do a lot of ref churn we'd consider unnecessary.
[ Parent
| on HN ]
Re:Apple is rewriting Foundation in Swift
by plorkyeran on Monday May 22, 2023 @02:01AM
(#36027947)
IME Swift’s refcounting is either incredibly inconsequential or a dealbreaker, with very little in between. They’ve done a very good job of optimizing it to the point where it’s barely measurable even in perf sensitive code… until you hit the scenarios where it completely murders performance and there’s nothing you can do about it.
Hopefully the upcoming ownership functional will help in those cases.
* * *
On apple hardware, uncontended refcounting (swift or objc) has the same perf as non-atomic refcounting. The cost exists, but it isn't terrible, once there's contention between threads the perf drops through the floor. The real killer is there are a bunch of places where the swift evaluation model means they're forced to ref churn, which comes up 100% typical workloads like the million triangle objects in my swift raytracer, all being hit by numerous threads :D