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).
