Garbage Collection Performance
The cluster focuses on debates about garbage collection (GC) latency, pauses, and efficiency in languages like Go and Java, comparing GC to manual memory management and its suitability for real-time and performance-critical applications.
Activity Over Time
Top Contributors
Keywords
Sample Comments
Garbage collection isn't slow. good GC systems have similar overhead to malloc/free.
Doesn't go's GC work as well as it does because it's a 'stop the world' single-threaded implementation?
Much more than "a realistic chance of optimizing everything else to the point that GC time becomes your biggest problem"?
Real-time GCs with microsecond latencies do exist.
You didn't have a bad experience with GC in the past, you had a bad experience with a single GC implementation, one which was almost certainly optimized for throughput and not latency and in a language that pushes you toward GC pressure by default. :)
Do you have a source for this? My understanding is Go's GC is much better optimized for low latency.
Why wouldn't it be? There's no forced GC, you can have custom application in arenas, etc. Pretty much all tricks used for low latency are available.
There are Java GCs that are optimized for latency. Check out project Shenandoah and ZGC for examples.
GC isn't a problem for realtime systems, if configured correctly. For example, have the GC running incrementally in a separate thread.
OP probably wants a Concurrent/MarkAndSweep GC rather than a Generational GC. because 16 ms is too much for game dev