--- Comment #121 from David Simcha <> 2011-04-14 19:59:28 PDT 
(In reply to comment #120)
> I understand the advantages of a moving GC - heap compaction allowing for an
> overall smaller managed heap etc., but I hope you understand that sacrificing
> speed for these goals is not an unilateral improvement for everyone.

Since we don't have any hard benchmarks conveniently available, let's assume
for the sake of argument that a precise/moving/etc. GC would be slower.  Your
case is a niche case and calls for a niche garbage collector implementation. 
D's GC is designed (IIRC) to allow selecting an implementation at link time. 
Eventually, someone could write a decent low-latency GC optimized for small
heaps for game programmers.  In the mean time, we could fork the current one. 
The stock GC, though, should handle the common cases, not a few game
programmers' corner case.

Configure issuemail:
------- You are receiving this mail because: -------

Reply via email to