4 ms·
First of all, traditional (tracing) GCs require more expensive runtimes and consume much more memory. ARCs are also much more predictable in their behavior and
by mannuch 2y ago
First of all, traditional (tracing) GCs require more expensive runtimes and consume much more memory. ARCs are also much more predictable in their behavior and pave the way for greater compile time optimizations. ARC is key in providing Swift its ability to maintain its low memory footprint compared to, say, Java.
Second, yes, ARC is a GC method. But when the language says "no garbage collector", they just mean no traditional (tracing) GC runtime because, for better or worse, tracing GC is what people think of when they hear "garbage collector".
- vips7L 2y ago> traditional (tracing) GCs require more expensive runtimes and consume much more memory Not really no. Look at go, D, nim, or any ahead of time compiled language. > ARC is key in providing Swift its ability to maintain its low memory footprint compared to, say, Java Again not really. Java has other issues. Like lack of value types, conservative escape analysis, needing extra memory for profiling and the jit, and HotSpot’s GCs are focused on server applications and are designed not to release memory until they’re about to run out. Even if this were true ARC trades memory for execution speed. I can’t find the exact paper right now but the ixy implementations showed that you end up spending an unhealthy amount of time just counting references when you stay in pure swift code. I think it was somewhere > 30%.
- saagarjha 2y agoThe ixy examples were definitely nowhere near being idiomatic code.
- vips7L 2y agoRight. They spend a lot of time in pure swift and not within its C++ runtime, but when you want to compare garbage collection algorithms that doesn't really matter. The fact is that ARC is slow and you spend a ton of time counting references. Something an alternative algorithm wouldn't have to do.