4 ms·
This is probably going to hurt performance a whole lot more than proper GC, because now the compiler throws in a whole bunch of retain/release statements where
by ori_b 15y ago
This is probably going to hurt performance a whole lot more than proper GC, because now the compiler throws in a whole bunch of retain/release statements where they aren't really needed.
Unless they're doing some pretty strong analysis to remove redundant reference operations.
- dirtyaura 15y agoI think it's still easier to ensure performant code as reference counting is more deterministic than GC. I assume you can turn off ARC for compilation unit if you want, so performance critical code can be manually managed.
- ori_b 15y agoNaieve reference counting incurs a bus lock across all processors on every assignment, more or less. That's quite painful.
- gonzo 15y agoHow many processors (cores) do most iOS devices have? GC is still supported on MacOS X.
- cpeterso 15y agoOne core, but the Apple A5 in the iPad 2 and iPhone 4GS/5 (the flagship devices for iOS 5) has two cores.
- kstenerud 15y ago95% of code can run an order of magnitude slower than "optimal" with no discernable degradation of the user experience. If a bus lock degrades your performance too much, either change your algorithm, or isolate that section of code and do it in another language that doesn't suffer the same performance issues.
- rsl7 15y agoAlso autorelease only applies to NS objects, not plain C data.
- deleted 15y ago[deleted]
- gte910h 15y agoI don't know about you, but 99% of my objective C code is quite formulaic with regards to memory management.
- ori_b 15y agoSure, but can the compiler prove that?
- flyosity 15y agoI'm fairly sure that the LLVM compiler is smarter than the smartest Objective-C code I could write, but your mileage may vary.
- deleted 15y ago[deleted]
- ori_b 15y agoI'm fairly certain that it doesn't do cross-translation-unit inter-procedure analysis, so it can't tell if, for example, the function from another file that you call does anything special that would make the removal of a retain before passing the object to the function an invalid optimization. It doesn't know that the object is only used in a thread-local context, so in many cases (eg, function args) it might not be able to assume that there is no concurrent refcounting action going on elsewhere, which eliminates other optimizations. By definition, compilers have to be conservative about what callers can do, when humans can simply say "This function is not thread safe", or similar. This is one reason that "real" GC is generally used instead of reference counting in all high performance garbage collected language. (In throughput-oriented systems, the GC is even a stop-the-world GC, since that removes quite a bit of concurrency/atomic operation overhead). The other big one is that you need a garbage collector anyways if you want things to work in the presence of cycles. EDIT: Perhaps someone with a Mac and access to this compiler can post some output of code with this feature enabled. I'd be curious to see what sort of output the compiler actually gives. This speculation is annoying :)