GC in D and synadard library.

[Chris Katko]

On Thursday, 21 December 2017 at 10:49:46 UTC, Dan Partelly wrote:
>
> I started to look into D very recently. I would like to know 
> the following, if you guys are so nice to help me:
>
> 1. What is the performance of D's GC, what trade-offs where 
> done in design , and if a in-deep primer on efficient usage and 
> gotchas of the current implementation exists.
>
> 2. GC is never good enough. What are the current plans in this 
> area for D. In general, please point me to the place where 
> current work on D is done.
>
> 3. I need to be able to run with GC totally disabled sometimes. 
> In the light of this:
>    - are there any features of core language which depend on 
> garbage collection ? (i.e unbound arrays, strings ..)
>    - are there any features from standard library which depend 
> on active garbage collection?
>    - Please point me to a list where there is an exhaustive 
> enumeration of which language features *and* library features 
> requires GC active. Looking at standard library docs I did not 
> seen markings which identify clearly and unequivocally what 
> requires GC active and what not.
>
> 4. Is Andrei Alexandrescu's book from 2009 on D still actual, 
> or the language evolution made it obsolete ?
>
> With thanks.

I make hobby/proto-type games and I've been doing it for 
well-over a decade at this point. Starting learning D and trying 
games with Allegro 5 and D the same way I used C++.

There's lots to learn. But so far it's a freaking DELIGHT to 
program in D compared to C++. It's so easy to reduce boilerplate, 
and extend code without huge swafts of boilerplate 
std::vector<std::vector<my_obj(1245,124512,taco())>> template 
code.

I'm intentionally ABUSING the GC so far by having every smoke 
particle (hundreds) with new ones allocate and and old ones 
deallocating every frame. I'm also developing on a tiny 
Chromebook with a Intel Celeron ~N2950 and only 2 GB of RAM 
(which Ubuntu eats most of).

I'm still getting 115+ FPS drawing 600 alpha-blended "cloud" 
bitmaps each frame, plus the smoke trails, and allocations.

There is a microstutter issue I'm diagnosing that may be related 
to GC. (After all, I AM intentionally abusing it so I can get a 
"feel" for it.) But it's not terrible. I plan to move to static 
pools for everything eventually but this is a viability study for 
D and the GC without going out of my way to disable/avoid the GC.

Merely turning on Open Broadcast Studio to capture video of my 
game for explanations takes more CPU time than my game.

So depending on what you want to design, I really second 
everyone's recommendation "don't worry about it until it's a 
problem." D is so adaptable that it's really easy to move away 
from the GC (assuming you write good code anyway).

Now, to that previous point of "don't worry about it." I 
absolutely get the apprehension when someone tells you that. But 
yeah, it's not that bad. If you do "heavy lifting" stuff with 
static allocations, and leave the GC for making lambdas and stuff 
like that super-easy to write code, it's a good combination.

As others have mentioned, you can even allocate memory that the 
GC has literally no idea about and will never collect.

I definitely recommend trying D. The best way for you to know if 
it suits YOUR requirements is really... make a test app like I'm 
doing. Code the way you normally do and see if the GC affects 
you. Absolute worst case you can port your program to C++ pretty 
quickly.