Hacker News Reader

Comment by shtopointo | Hacker News Reader

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.

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.

Ah I see very interesting, thanks!

Bad, like really bad.

https://github.com/ixy-languages/ixy-languages

Interesting, 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

It'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.

Because it's too slow.

Great explanation, thanks...

Reply on news.ycombinator.com