> Thank's for the link to your GC benchmarks; They really show how good Boehm > can be. What are Boehm's disadvantages compared to the others?
1. It's a stop-the-world collector, sacrificing latency for throughput. While pause times are still typically only a fraction of a second unless you're using very large heaps, they're still too big for latency-sensitive applications. It can be a perfectly good choice for batch programs, especially parallelized data crunching, or even some interactive applications that aren't too sensitive to latency. 2. It's a fully conservative GC; unlike the native Nim GC options, it does not just scan the stack conservatively, but any object or memory region that may contain pointers. On 32-bit systems in particular, this can lead to problems with memory being retained even though it's inaccessible. While you can in principle configure the Boehm GC so that only the stack is scanned conservatively (as for the Nim GC), this would require quite a bit of work, as you'd have to specify type layout and roots in the way that the Boehm GC expects it. I'll also add (as noted in the readme file) that the performance differences are inflated compared to well-written real world imperative programs. The benchmark does almost nothing but allocating and deallocating memory, while real world imperative programs should at most spend 10%-20% of their time on it. The reason why I wrote the benchmark was not to actually make some universal statement about allocation performance, but to debunk a particularly ignorant article about how GC cannot be competitive with malloc() without incurring massive overhead. For that, I had to construct something of a worst case situation. For most imperative applications where you don't need to tweak performance or need specific GC features, the choice of GC shouldn't matter much, as the bulk of the time will be spent doing non-allocation related work.
