The GC and performance, but not what you expect

[Steven Schveighoffer via Digitalmars-d]

On Thu, 29 May 2014 06:09:17 -0400, Atila Neves <atila.neves at gmail.com>  
wrote:


>
> The GC is preventing me from beating Java, but not because of
> collections. It's the locking it does to allocate instead! I
> don't know about the rest of you but I definitely didn't see that
> one coming.

Just checked. It used to be a long time ago that single threaded apps did  
not take the lock. It appears not to be the case any more, the lock is  
always taken.

The explanation in the comment is that finalizers may spawn a new thread.  
See  
https://github.com/D-Programming-Language/druntime/blob/master/src/gc/gc.d#L410

Surely we can figure this out...

More and more, it's looking like we are going to start needing  
thread-local pools for thread-local allocations.

To work around, you might be able to pre-allocate all your data before  
starting, and make judicious re-use of buffers. But of course, this may  
make the code so much more ugly, which it shouldn't have to be.

-Steve