6 ms·

An interesting realization that it could, though. Overwhelming majority of MacOS/iOS software is written on Obj C and Swift, which have the same underlying sem

by slver 6y ago

An interesting realization that it could, though. Overwhelming majority of MacOS/iOS software is written on Obj C and Swift, which have the same underlying semantics. That said ARC doesn't have such a great impact on performance as some people (esp. fans of Java's GC etc.) would convince you. Most ++/-- operations on the refcount are eliminated by the compiler.

skohan 6y ago
The worst case performance is very bad though. I have done some playing around with pushing Swift in terms of performance, and it's very hard because of ARC.
- foobiekr 6y ago
  Code in the fastpath must not generate substantial garbage whether using ARC or a gc. That's just a coding error.
  - skohan 6y ago
    It's not about garbage creation, is about reference cost. With ARC, you pay a penalty every time you pass a reference type, not only for memory churn. You can avoid this using value types, but this often results in a lot of unnecessary copying. It's not unavoidable, but Swift doesn't give good tools for avoiding ARC-based performance cliffs, so it takes a lot of profiling and effort compared to other languages.
  - astrange 6y ago
    It's ok to generate garbage if it goes away immediately; that's essentially a stack allocation. Performance problems come up when you have a mix of lifetimes. (that slows GCs down and causes heap fragmentation outside copying GCs)
pjmlp 6y ago
Some fans do measure, and know the difference from marketing and reality in regards to tracing GC versus reference counting marketing material. https://github.com/ixy-languages/ixy-languages https://github.com/ixy-languages/ixy-languages
- astrange 6y ago
  Wallclock time isn't the only performance metric to care about. ObjC had a GC in the past and lost it in favor of ARC for a reason; it's a poor fit for iPhone-sized devices.
  - pjmlp 6y ago
    That was the marketing reason, the official reason was that fitting a GC into a language with C memory model wasn't never going to work, and there were plenty of crashes and memory corruptions coming out of that. So they made the only sensible decision, and just like Microsoft did with COM, they added support to the Objective-C compiler to automate retain/release messages in OS X Frameworks. Naturally being Apple, that pivot had to be sold in a way that the reason was being of RC being better and not because of the technical failure to have a tracing GC in Objective-C , while remaining compatible with C memory model. Apparently, moving the GC document with all its caveats regarding possible programming issues, out of search index also helps to keep the story as well. https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/GarbageCollection/Introduction.html https://developer.apple.com/library/archive/documentation/Co...
    - astrange 6y ago
      No, the performance issues are real. GC programs have more page demand and higher peak memory use, which is specifically what the iOS memory model (jetsam and memory compression) can't deal with well. They can have some wins due to compacting. There is of course a GC language on iOS (JavaScript) but expensive webpages get killed quickly.
      - pjmlp 6y ago
        And yet Microsoft was able to do very good phones with GC languages with very good performance for 200 euros, maybe Apple should talk to their runtime engineers.
        6y ago

by slver 6y ago

skohan 6y ago

The worst case performance is very bad though. I have done some playing around with pushing Swift in terms of performance, and it's very hard because of ARC.

foobiekr 6y ago
Code in the fastpath must not generate substantial garbage whether using ARC or a gc. That's just a coding error.
- skohan 6y ago
  It's not about garbage creation, is about reference cost. With ARC, you pay a penalty every time you pass a reference type, not only for memory churn. You can avoid this using value types, but this often results in a lot of unnecessary copying. It's not unavoidable, but Swift doesn't give good tools for avoiding ARC-based performance cliffs, so it takes a lot of profiling and effort compared to other languages.
- astrange 6y ago
  It's ok to generate garbage if it goes away immediately; that's essentially a stack allocation. Performance problems come up when you have a mix of lifetimes. (that slows GCs down and causes heap fragmentation outside copying GCs)

pjmlp 6y ago

Some fans do measure, and know the difference from marketing and reality in regards to tracing GC versus reference counting marketing material. https://github.com/ixy-languages/ixy-languages https://github.com/ixy-languages/ixy-languages

astrange 6y ago
Wallclock time isn't the only performance metric to care about. ObjC had a GC in the past and lost it in favor of ARC for a reason; it's a poor fit for iPhone-sized devices.
- pjmlp 6y ago
  That was the marketing reason, the official reason was that fitting a GC into a language with C memory model wasn't never going to work, and there were plenty of crashes and memory corruptions coming out of that. So they made the only sensible decision, and just like Microsoft did with COM, they added support to the Objective-C compiler to automate retain/release messages in OS X Frameworks. Naturally being Apple, that pivot had to be sold in a way that the reason was being of RC being better and not because of the technical failure to have a tracing GC in Objective-C , while remaining compatible with C memory model. Apparently, moving the GC document with all its caveats regarding possible programming issues, out of search index also helps to keep the story as well. https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/GarbageCollection/Introduction.html https://developer.apple.com/library/archive/documentation/Co...
  - astrange 6y ago
    No, the performance issues are real. GC programs have more page demand and higher peak memory use, which is specifically what the iOS memory model (jetsam and memory compression) can't deal with well. They can have some wins due to compacting. There is of course a GC language on iOS (JavaScript) but expensive webpages get killed quickly.
    - pjmlp 6y ago
      And yet Microsoft was able to do very good phones with GC languages with very good performance for 200 euros, maybe Apple should talk to their runtime engineers.
      - 6y ago