Slow GC?

[Vladimir Panteleev]

On Fri, 14 Mar 2008 04:38:23 +0200, bearophile <bearophileHUGS at lycos.com> wrote:

> While writing a program I have seen it's quite slow (about 35-40 seconds to run a program that requires less than 8 seconds to run with Python), I have progressively simplified it, to the following D code, able to show a similar problem:

Splitting a huge block of text by whitespace will cause an array that's comparable to the size of the original text (a slice is 8 bytes, so if words are 6-7 characters long by average, the size would be the same). The slowdown appears because the GC needs to look up every one of those pointers, which point to the same large memory region.

I made a patch for Tango's GC which caches the last page during the "mark" part of the scan. This reduces the execution time of your program tenfold for me, but it will only work when there's many consecutive pointers to the same GC page which is part of a big (>2048 bytes) allocation. There should be no noticeable performance penalty for the general case (as the overhead is just one compare and sometimes an assignment), so I've created an enhancement ticket:

http://dsource.org/projects/tango/ticket/982

Interestingly, when I first compiled your program with Tango's runtime, and it ran a lot slower. I found the bottleneck, then created a ticket with an explanation and patch here:

http://dsource.org/projects/tango/ticket/981

I also have a patch for Phobos (for expanding arrays, not the GC), but it doesn't yield a big improvement (about 13% faster).

-- 
Best regards,
 Vladimir                          mailto:thecybershadow at gmail.com