6 ms·

ARC are less likely to get paused as memory release are amortised rather than gather and swept. Also, LLVM static analyze is so good at figuring out your code

• rayiner 12y ago
  Maybe not so much: https://news.ycombinator.com/item?id=7849631 https://news.ycombinator.com/item?id=7849631
• deleted 12y ago
  [deleted]
• tormeh 12y ago
  Can't cyclic reference be fixed by a garbage compiler occasionally cleaning up those things? I think that's how Python does it, not that Python is a beacon of performance, but it's possible.
• cromwellian 12y ago
  What LLVM static analysis can be done to figure out the lifecycle of objects also applies to other GC algorithms. ARC may be less likely to get memory paused on release, but ARC doesn't compact free memory, and therefore fragmentation can cause object allocations (malloc) to become more expensive, possibly leading to pauses. If you use non-copying GC that doesn't compact (ARC doesn't compact), then there are low pause GC algorithms out there that give pretty good bounds (e.g. 5ms pause). I'd like to see actual benchmarks of both ARC and say, mark-and-sweep on a mobile device rather than speculation and opinion, and both benchmarks must get the same static compilation treatment. That is, if escape analysis tells you that the lifetime of the object is bounded by the current stack frame, then allocate it on the stack, and don't penalize the non-reference-counted GC by allocating 100% of everything on the heap.
  • sitharus 12y ago
    ARC may be slower than a good GC, but what it has is deterministic behaviour. A 10ms pause could be tolerable if you know when it will happen. A fair few years ago I worked in the murky world of J2ME games, and a common pattern was byte[] _variables = new byte[1024] so you could ensure there were no GC pauses.
    • pcwalton 12y ago
      > A fair few years ago I worked in the murky world of J2ME games, and a common pattern was byte[] _variables = new byte[1024] so you could ensure there were no GC pauses. That's not the same as ARC, though. The Java equivalent to ARC would be something like having an array of volatile reference counts to go with your variables and fiddling with those at most accesses.
      • sitharus 12y ago
        Not the same, but they had the same problem - GC pauses when it likes, not when you like. If you know calling move_hero() takes 23ms, 15 of which is ARC you can plan for that. You can't plan for move_hero() taking 7ms, except when GC happens.
        • cromwellian 12y ago
          Depending on VM, Java developers can plan where the pauses happen. One way they do that is by object pooling, another is by using DirectBuffers/off-head memory. A third way to do it is with scoped heaps. It's not like tons of games haven't been shipped with non ref-count GC. Minecraft being the most famous, but games on Unity3D/Mono can have non-ref count GC. Lua is shipped in tons of game engines and uses classic GC. Regardless of whether you are using automatic GC, or if you are using malloc/free, you can't write a high performance game without carefully working around memory issues. Even C/C++ games like Max Payne have shipped with frame hiccups caused by poor malloc/free behavior that had to be fixed with custom allocators. If you're writing a game, you have to pay attention to what you're doing. But do non-framrate limited games and regular apps need ref-count GC? I suggest no, they do not.