[xmlp] the recent garbage collector performance improvements
dsimcha at yahoo.com
Wed Feb 1 11:35:19 PST 2012
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).
More information about the Digitalmars-d