gc causes unpredictabilities in performance*. With games it tends to be worst case performance that matters.
I would reccomend using std.experimental.allocator (even if you still use the default GC backed allocator). This will allow you to swap out your allocator for a more specialised one as your requirements become more concrete. auto foo = new CustomStruct(); becomes auto foo = allocator.make!CustomStruct(); The next thing you probably want is @nogc - Last time I checked getting IAllocator objects are a bit tricky to use in @nogc code. Currently I am using https://github.com/radcapricorn/alloctraits to get around this limitation (You will still need an allocator that doesn't use the GC, I use Mallocator for test purposes). * The GC itself is deterministic, but it is really easy to write code that triggers GC pauses at times that is difficult track down. On Sat, Apr 7, 2018 at 7:55 AM, Chris Katko via Digitalmars-d-learn < digitalmars-d-learn@puremagic.com> wrote: > I'm in the same boat. I do games. But I love D's syntax and template > power. So I'm doing a full experiment. > > Honestly, if D is that big a liability, you'll encounter it long before > it's "too late" to port it to C++. > > Last night I had stuttering issues, but I realized there was a single, > C-function, being called too many times (and never deallocating!). > > But previously, I've also had stutter issues. Now granted, I test on a > "crap" laptop 2 GB RAM / Celeron processor. But it'll be 60 FPS ... then > spike down. If this happens again with my current project, what I'm going > to do, is hack the open source garbage collector to fire off an > event/console message EVERY TIME it actually pauses to collect. Because > it's possible the GC isn't actually the problem, or, some simple change to > a line of code may prevent the GC from being a problem. > > That said, there's also @nogc (but that's also a bit of a lie because they > never tell you that ANY THREAD running GC code can pause ALL THREADS for a > collection.) > > But if you're making games, you should really be using static pools > anyway. What's the MAXIMUM number of objects/trees/maps your game will have > at a time? It's simple (regardless of D, C, Python, or Lua). Static. Pools. > Basically, you just allocate at startup a simple fixed-length array for all > your objects. That way, you're never asking the OS for memory = Never > needing the garbage collector. If you don't use all that memory? Who cares. > RAM is cheap. And if your program CAN swell in size, that means your > low-end PCs will fail without knowing why. > > So you just put all your objects in fixed length arrays of size > MAX_OBJECTS, MAX_ENEMIES, MAX_ITEMS, etc. And deleting an object is as > simple as erasing it, or marking it as "bool is_deleted = true;" and adding > a new object is simply finding the first "is_deleted" and re-running the > constructor / re-using the carcass of the dead object. > > 99% of AAA studios use static pools. Now technically, static pools are > "chunks" of fixed length arrays. So you could have one pool for a "map", > and start loading another pool for the next map you're going to enter, and > then when you finally transfer to the next map, you then free the static > pool by marking it as deleted. And repeat as necessary. So it's a very > macro-level amount of allocations. We're talking like, less than a dozen > actual entities. (Depends on gametype, of course. But the > order-of-magnitude helps convey it.) >