"Rainer Schuetze" <r.sagita...@gmx.de> wrote in message 
> This shows that removing most of the allocations was a good optimization 
> for the dmc-Runtime, but does not have a large, but still notable impact 
> on a faster heap implementation (the VS runtime usually maps directly to 
> the Windows API for non-Debug builds). I suspect the backend and the 
> optimizer do not use "new" a lot, but plain "malloc" calls, so they still 
> suffer from the slow runtime.

On a related note, I just tried replacing the two ::malloc calls in rmem's 
operator new with VirtualAlloc and I get a reduction from 13 seconds to 9 
seconds (compiling "dmd std\range -unittest -main") with a release build of 

Reply via email to