[xmlp] the recent garbage collector performance improvements

[dsimcha]

Interesting.  I'm glad my improvements seem to matter in the real 
world, though I'm thoroughly impressed with the amount of 
speedup.  Even the small allocation benchmark that I was 
optimizing only sped up by ~50% from 2.057 to 2.058 overall and 
~2x in collection time.  I'd be very interested if you could make 
a small, self-contained test program to use as a benchmark.

GC performance is one of D's biggest weak spots, so it would 
probably be a good bit of marketing to show that the performance 
is substantially better than it used to be even if it's not great 
yet.  Over the past year I've been working on and off at speeding 
it up.  It's now at least ~2x faster than it was last year at 
this time on every benchmark I've tried and up to several hundred 
times faster in the extreme case of huge allocations.

On Wednesday, 1 February 2012 at 18:33:58 UTC, Richard Webb wrote:
> Last night I tried loading a ~20 megabyte xml file using xmlp 
> (via the
> DocumentBuilder.LoadFile function) and a recent dmd build, and 
> found that it
> took ~48 seconds to complete, which is rather poor.
> I tried running it through a profiler, and that said that 
> almost all the
> runtime was spent inside the garbage collector.
>
> I then tried the same test using the latest Git versions of 
> dmd/druntime (with
> pull request 108 merged in), and that took less than 10 
> seconds. This is a
> rather nice improvement, though still somewhat on the slow side.
>
> Some profiler numbers, if anyone is interested:
>
> Old version:
> Gcxfullcollect: 31.14 seconds, 69.26% runtime.
> Gcxmark: 4.84 seconds, 10.77% runtime.
> Gcxfindpool: 2.10 seconds, 4.67% runtime.
>
> New version:
> Gcxmark: 11.67 seconds, 50.77% runtime.
> Gcxfindpool: 3.58 seconds, 15.55% runtime.
> Gcxfullcollect: 1.69 seconds, 7.37% runtime.
>
> (Assuming that Sleepy is giving me accurate numbers. The new 
> version is
> definately faster though).