3 ms·

Curious, how "real time" can a large application get in Go by judiciously working with pre-allocated structs and slices? Perhaps if the underlying system librar

• hedgehog 12y ago
  That lets you make GC infrequent but the amount of heap will determine the pause time when the GC comes calling. If you have a large number of live objects with pointers in them then pauses are unavoidable with the current Go GC, it sounds like if all goes according to plan things will be a lot better in 1.5 though.
  • TylerE 12y ago
    If you're pre-allocating you can just turn the GC off ;)
    • hedgehog 12y ago
      Certainly if you could get away from all allocations but it's pretty likely you'll end up with some from the standard library or some other external code.
• twotwotwo 12y ago
  More than many think. :) You can recycle objects to reduce GC frequency, reduce the number of pointer-containing objects to speed up the mark phase, batch or avoid allocations to speed the sweep phase. The sheer brawn of modern chips helps esp. given multicore GC; just sweating hotspots (e.g., big buffers) can do a lot; worst case, sometimes apps can be decomposed well into more processes each with their own smaller heaps. When GC comes up here (and not only on Go things), a lot of comments pop up that are like "welp, [tool] is no use for me if GC is involved," sometimes with a horror story or worst-case scenario. Sometimes I'm sure that's entirely rational and comes down to the type of app they work on (I don't wanna rewrite Unreal Engine in Go), but sometimes I wonder if whoever's saying it just doesn't know much about GC in practice.