Hacker News Reader

Comment by Eric_WVGG | Hacker News Reader

doesn’t seem cool to admire Apple technologies, but ARC seems to work amazingly well with zero CPU overhead

It's not at all zero CPU overhead, not even close. retain & release are thread-safe, meaning atomic ref count. Very comparable in cost to std::shared_ptr<T> or Rust's Arc<T>. Both of which also automatically insert the calls to inc & dec ref counts.

It's cool that you don't need to bother with specifying the type as being std::shared_ptr<T> or Arc<T>, but it's not particularly novel, either. It's "just" syntax sugar (or lack of syntax sugar I guess?)

Almost but not quite. Clang has very special rules around ARC that allow it to perform additional optimizations that would otherwise be illegal [1].

[1] https://clang.llvm.org/docs/AutomaticReferenceCounting.html#...

That just lets it release earlier, not retain/release less often.

ARC can't do anything magic here vs. something like really careful use of std::move & const references.

ARC optimizations do let it retain/release less often. For example, instead of a callee adding the return value to an autorelease pool then having the caller immediately retain the returned value, the autorelease+retain pair can be elided entirely.

> For example, instead of a callee adding the return value to an autorelease pool then having the caller immediately retain the returned value, the autorelease+retain pair can be elided entirely.

Are you just referring to standard RVO? If you return a std::shared_ptr in C++ today you won't get the equivalent of retain+release, either, RVO avoids that.

Did you even take a look at the doc I posted?

> For example, if the user puts logging statements in retain, they should not be surprised if those statements are executed more or less often depending on optimization settings

> In general, ARC does not perform retain or release operations when simply using a retainable object pointer as an operand within an expression

> However, C and C++ already call this undefined behavior because the evaluations are unsequenced, and ARC simply exploits that here to avoid needing to retain arguments across a large number of calls.

> ARC performs no extra mandatory work on the caller side, although it may elect to do something to shorten the lifetime of the returned value.

>retain & release are thread-safe

That's optional tho, and I never use it that way.

Do you have a link to what you're referring to? Apple's docs clearly state retain/release are thread safe.

Are you using your own implementation of retain & release or something?

For sure. It's entirely stock:

  @property (strong, nonatomic) UIView* unselectedTabsView;

"nonatomic" means avoid synchronization code. This code is not thread safe for that reason, but I never do cross-thread access anyways.

That means reads of/writes to the property are nonatomic. Certain (not all) ARC refcount functions are required to be atomic no matter what.

It’s not zero — those -retain and -release calls still exist when necessary and have a small penalty — but it does minimize them well, and is lower overhead and vastly more predictable than GC.

It's a little better than that, because the overhead of ObjC method dispatch is avoided. There are no calls to -retain or -release (if the receiver hasn't overridden those methods), it's just a C function call to objc_release et al. No objc_msgSend involved.

Reply on news.ycombinator.com