3 ms·
Sorry, don't know enough of the theory behind this – why is that not a good fit? Happy to read up on this if you don't have the time to type it up.
by shtopointo 5y ago
Sorry, don't know enough of the theory behind this – why is that not a good fit?
Happy to read up on this if you don't have the time to type it up.
- zozbot234 5y agoBecause it's too slow.
- shtopointo 5y agoGreat explanation, thanks...
- danappelxx 5y agoI’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.