3 ms·

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

seandougall 8y ago
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.
- favorited 7y ago
  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.
kllrnohj 8y ago
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?)
- vlovich123 7y ago
  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#arc-optimization https://clang.llvm.org/docs/AutomaticReferenceCounting.html#...
  - kllrnohj 7y ago
    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.
    - favorited 7y ago
      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.
      - kllrnohj 7y ago
        > 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.
        vlovich123 7y ago
        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.
- DenisM 7y ago
  >retain & release are thread-safe That's optional tho, and I never use it that way.
  - kllrnohj 7y ago
    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?
    - DenisM 7y ago
      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.
      - favorited 7y ago
        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.

favorited 7y ago
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.

kllrnohj 8y ago

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?)

vlovich123 7y ago
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#arc-optimization https://clang.llvm.org/docs/AutomaticReferenceCounting.html#...
- kllrnohj 7y ago
  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.
  - favorited 7y ago
    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.
    - kllrnohj 7y ago
      > 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.
      - vlovich123 7y ago
        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.
DenisM 7y ago
>retain & release are thread-safe That's optional tho, and I never use it that way.
- kllrnohj 7y ago
  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?
  - DenisM 7y ago
    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.
    - favorited 7y ago
      That means reads of/writes to the property are nonatomic. Certain (not all) ARC refcount functions are required to be atomic no matter what.