Does the GC explain why Gcc has got so slow?Very possibly it does. When Apple was still contributing (back in the 4.0 days) someone (I think it was Mike Stump) ran shark over it, and saw a horrifying rate of L2 cache misses, something like one every twenty instructions if I recall. It appears that the GC's largest cost is not when it runs at all, but what it does to the program's locality of reference: scatters it all over the place, leading to absolutely pessimal cache behaviour.
GCC has been carefully migrating selected speed-critical things back into obstacks ever since: they may be really annoying (freeing must be in reverse order of allocation), but they are contiguous, and that's sometimes a major benefit.
(And, y'know, I did think that the 45-second pauses were a crippling bug, but then most other things on my system also had huge pauses at the time: 6Mb RAM in 1998 was not pleasant. The real problem was that my system was hugely under-RAMmed.)
With the smallest machine I regularly work on now having 12Gb RAM, it's amazing how little I can force myself to care about swap-induced problems and OOM. At least, for the next couple of years, until KDE4.9 or GNOME 3.5 bloats up and uses it all up again.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds