Edi Weitz <[EMAIL PROTECTED]> writes: > The good thing: It's not Gerd's PCL that's responsible for the > slowdown.
That's good news! > The bad thing: Something that's relatively new in CMUCL[1] seems to be > responsible for a significant slowdown in GC times. That's bad news, because most of the stuff that's currently new in HEAD is is from me, too ;). > After fiddling around with various test cases I finally saw that the > difference between the old "fast" code and the new "slow" code was > always exactly the GC time. CL-PPCRE was just a good lackmus test for > this because it has to cons a lot to create scanners. > > I then switched to the 18e-pre1 binaries from 2003-03-23 and found the > same results - GC is slower by a factor of about 10 to 15! I think > that's quite a lot and I wonder if that's considered acceptable. Certainly not acceptable. I just haven't noticed so far that there is a bug, although I'd thought I'd noticed a 10x GC slowdown. Strange. I'll investigate this further. Thanks for tracking it down. Actually, there are only two candidates that could cause a GC slowdown, I think: the control stack checking or the new code for weak hash tables. Let's see. I'll come back to you when I find something.
