On 7 January 2012 23:26, Walter Bright <newshound2@digitalmars.com> wrote:

There are more options with D:

3) Disable GC from collecting during critical parts of the code, i.e. you can still new all you want, it just won't run collection cycles.

This may be nice, but there is never a 'non-critical' part of a game where I can spare 5...10...15ms (I hear 15ms quoted often, that's a *whole* frame) to let the GC do its thing.

4) Pre-allocate all necessary data before entering the critical sections. You have to do this anyway with C++ if you have hard realtime constraints, as C++ makes no guarantees about how long new or malloc() will take (and it cannot).

This will obviously happen anyway (and with strict allocation requirements... I'd like D allocators at some point, or this'll get messy with pointers), but that doesn't help, for instance, bearophile's example of a pointless allocation assigning a literal to a stack array, or various other trivial allocations that go on here and there like that...

I'm also dubious about string allocations. I'd quite like a way to have strings allocate in their own little self contained heap. They can use GC, but they need to be separated into their own little memory region, and not pollute/fragment the rest of the heap.

Engine code tends to create large allocations, megabytes in size, and with very course alignment rules, 4k for instance, and little allocations fragmenting memory can cause major problems/gaps...