3 ms·
I’m not sure if it’s fair to dismiss ARC as a bad fit for server-side work in general, but the typical argument is that atomic retain/release operations become
by danappelxx 5y ago
I’m not sure if it’s fair to dismiss ARC as a bad fit for server-side work in general, but the typical argument is that atomic retain/release operations become quite expensive when you share memory across threads. It’s easy to imagine, for example, how a global database connection pool accessed on every request across dozens of threads would have non-zero ARC overhead.
In practice, compiler optimizations reduce the amount of retain/release pairs emitted, but I have no idea how the resulting performance compares to GC languages.
- shtopointo 5y agoAh I see very interesting, thanks!
- pjmlp 5y agoBad, like really bad. https://github.com/ixy-languages/ixy-languages https://github.com/ixy-languages/ixy-languages
- danappelxx 5y agoInteresting, thanks for sharing. Related thread on Swift forums [1] seems to suggest that the latest Swift compiler would generate code that performs a lot better than the Swift 4.2 version. I'm interested in checking that for myself. [1]: https://forums.swift.org/t/swift-performance/28776 https://forums.swift.org/t/swift-performance/28776
- loeg 5y agoIt's mostly not the atomic op overhead that's expensive, though -- it's the sharing. You can write shared-nothing algorithms using ARC objects that are local to a single thread or core, and while it will be slightly more expensive than RC objects, the N^2 effect of sharing between N cores won't occur.