Frameworks and libraries

[H. S. Teoh]

On Thu, Sep 14, 2023 at 07:40:24PM +0000, bachmeier via Digitalmars-d wrote:
> On Thursday, 14 September 2023 at 17:32:19 UTC, H. S. Teoh wrote:
[...]
> > Yeah, in 90% of the use cases, the GC actually helps much more than
> > it hurts.  Two of the biggest advantages:
> 
> I'd add another disadvantage of the GC that probably won't be there:
> performance.
> 
> I don't find that avoiding the GC speeds up my code that often.
> Sometimes it helps to disable the GC if I'm reading a very large
> number of elements into an AA of AA's.

In one of my projects, I found that calling GC.disable and then doing my
own scheduling of when GC.collect runs, improved my performance by
40-60%.  It's another way of boosting performance while still enjoying
the benefits of having a GC.


> What consistently improves performance is avoiding allocation of large
> blocks of memory - and it's easier to do that correctly when you're
> using the GC. If you don't allocate, the GC will not run, problem
> solved.  Completely avoiding the GC is a sensible if you're writing a
> game, but at best not that helpful if you just want your program to
> run faster.

When it comes to performance issues, I have 3 pieces of advice:

1) profile
2) profile,
3) profile.

;-)  IOW, don't automatically assume the GC (or anything, really) is the
cause of your performance issues.  Use a profiler to find out the real
culprit.  If it *is* the GC, I'd venture to guess that 80% of the time
it can be managed by careful use of GC.disable, GC.collect, and
GC.enable.  Generally speaking, you do not need your entire program to
be @nogc, except in a very small number of very specific use cases.


T

-- 
A mathematician learns more and more about less and less, until he knows everything about nothing; whereas a philospher learns less and less about more and more, until he knows nothing about everything.