[Issue 20219] Idle D programs keep consuming CPU in Gcx.scanBackground

[d-bugmail at puremagic.com]

https://issues.dlang.org/show_bug.cgi?id=20219

--- Comment #4 from Rainer Schuetze <r.sagitario at gmx.de> ---
(In reply to Vladimir Panteleev from comment #3)
> How costly is this overhead?

I don't have hard numbers, but IIRC the overhead was a couple of ms for tests
that only ever run a single collection.

> 
> I think your suggestion is a good idea, and we should balance the time the
> threads stay idle with the overhead of starting them. E.g.: let them shut
> down if they have been idle for more than 100x-1000x the time that would be
> needed to start them again.

Possible, but I'm not sure it is worth the effort. The threads use only a small
stack of 16kB and are now just waiting for a common event.

> 
> (In reply to Rainer Schuetze from comment #2)
> > When making it opt-in, only few programs would
> > actually benefit from that, because people won't bother to change the
> > defaults.
> 
> Not sure what you're trying to say, as this argument applies to both opt-in
> and opt-out, with each being a compromise.

True, it's a compromise trading some thread handles and memory for better
performance in most cases. I suspect most people (and especially the users of
the program more than the developer) want the program to run faster, so the
default should be that.

> 
> What I'm worried about of, if this were to become normalized, reactions like
> "Why does this tiny program I just installed need so many threads? Oh right,
> it's written in D, that language with that bloated runtime and garbage
> collector which needs a dozen threads to work properly. What a mess, why
> hasn't someone rewritten it in Rust yet!".

When I start any program in a debugger on Windows, I see 3 additional threads
already running for that process when entering WinMain. I haven't seen any
complaints about that.

--