https://issues.dlang.org/show_bug.cgi?id=20219
--- Comment #4 from Rainer Schuetze <[email protected]> --- (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. --
