Adding a new imediate type
bryce at kampjes.demon.co.uk
Fri Jan 6 20:40:23 UTC 2006
Andreas Raab writes:
> To be honest - I don't expect this to make any significant difference.
> Simply because allocation speed is only a fraction of the cost of even a
> loop like:
> 1 to: 1000000 do:[:i| 0 at 0]
> If you actually measure that you'll find that about half of the time is
> spent in GC and that's for the *optimal* (and completely unrelatistic)
> case of zero survivors (meaning GC is a lot faster than usual) and not
> even counting the loop overhead. If you actually measure the loop
> overhead (which creates no GCs) and subtract that from the tally results
> you end up with something that says that more than 80% of the remaining
> time (which is due to actual allocation) is spent in garbage
I get 22% of the time inside the GC with 369ms with the 0 at 0s and 101ms
with the 0 at 0 commented out so on my machine with my VM and current
compile flags so 30% of the object creation overhead is GC and 70% is
allocation. That's running interpreted code. So using my measurements,
I could get realistically get a two to three times gain in compiled
I'm measuring GC time with TimeProfileBrowser. Unless you're measuring
with a more accurate tool then I guess platform matters for relative
It's very possible that GC efficiency depends on CPU/memory bandwidth.
My current machine has a 10% faster clock and 8 times the memory
bandwidth of my old machine.
Modifying the GC to use a copying collector for new space will speed
up GC performance noticably.
Thanks for the interesting emails. And yes, this is enough theory
without proper profiling.
More information about the Squeak-dev