OSNews thread here degenerates into GC vs not

[Bill Baxter]

Sean Kelly wrote:
>  Second, I haven't yet ported or written an app in D that has such
> refined allocator requirements that the nuances of a GCs performance 
> would matter.  Perhaps someone who's written a game in D could comment 
> on the obstacles they encountered related to garbage collector performance?

Generally for a realtime 3D app you want to avoid creating and 
destroying things on a per-frame basis as much as possible.  If you do 
lots of alloc/free then performance will suffer.  It's a fact of life. 
That's true for either GC case or explicitly managed memory.   So for 
example when you make a cool particle system effect you don't allocate 
each particle, animate it, then destroy it.  You usually pre-allocate a 
fixed number of them and just reuse those over and over.

A lot of game developers also use custom allocators like dlmalloc 
because the platform's malloc isn't fast enough.  Writing fixed-sized 
custom pool allocators is also fairly common.  But that kind of thing is 
perfectly do-able in D too.

Basically I think the kind of games that would need custom memory 
management with D are probably the same kinds of games that would need 
it under C/C++ as well.  Poor floating point performance may be a bigger 
issue for fancy 3D games than GC, when it comes down to it.

--bb