Do you use D's GC?

[H. S. Teoh]

On Sun, Aug 01, 2021 at 08:54:05AM +0000, Kirill via Digitalmars-d wrote:
> It's interesting to hear do you use D's GC? Or do you use your own
> custom memory management structure?
> 
> How performant is GC?
> 
> The reason I'm asking is I'm planning to dive into 3D game dev with D
> as a hobby in an attempt to create a game I dreamed of since I was a
> kid. I'd like to know if GC is worth using at all, or should I go with
> 100% manual memory management.
[...]

My approach to D's GC is:

(1) Use it by default until it starts showing up as a bottleneck in your
profiler.

(2) When it does show up as a bottleneck, the fix is often simple and
yields good benefits. E.g., in one of my projects, after the GC showed
up as a bottleneck, I quickly pinpointed the problem to a function in an
inner loop that was allocating a new array every iteration.  Fixing that
to reuse a previously-allocated array (maybe about 5 lines' change)
immediately gave me 20-30% performance boost.  There were a couple of
other similar small code changes to reduce GC pressure, and replace some
small bits of GC code in inner loops where performance matters the most.

(3) If performance is still not good enough, there are other ways of
controlling the GC. In the aforementioned project, for example, after
the array optimization I found that GC collections were taking place too
often. So I added GC.stop to the start of my program, and scheduled my
own calls to GC.collect at a lower frequency, and got about another
20-30% performance improvement.

Overall, I think I got about 50-60% performance improvement just by
several small code changes to an essentially GC-centric codebase.  By
writing GC code I saved countless days of writing code for manually
managing memory (and weeks of pulling out my hair to debug said code).
Only in actual hotspots where the GC becomes a hindrance, I spent some
focused effort to either optimize GC usage, or replace small parts of
the code (in inner loops and other bottlenecks) with manually-managed
memory.  Much faster development time than if I had written *everything*
to be @nogc.  Most of that effort would have been wasted on code that
doesn't even lie in the bottleneck and therefore doesn't actually matter
to performance.

tl;dr: don't fear the GC, just use it freely until your profiler has
actually identified the GC as the bottleneck. Then strategically
optimize those hotspots, optionally replace them with @nogc code, etc.,
with much less effort than writing your entire application with @nogc.


T

-- 
"Hi." "'Lo."