> I've modified his patch to remove some unnecessary calculations. > > before after > gc_alloc_new.pbc 4.155999 3.756002 > gc_alloc_reuse.pbc 16.574 9.423002 > gc_generations.pbc 4.025 5.278002 > gc_header_new.pbc 3.686 3.615 > gc_header_reuse.pbc 5.577999 4.908003 > gc_waves_headers.pbc 3.815002 3.675001 > gc_waves_sizeable_data.pbc 8.383002 9.403999 > gc_waves_sizeable_headers.pbc 5.668 6.268999
Yet another correction to my results...the 'after' benchmarks are from a completely different build of parrot. Unfortunately, the new results aren't any easier to explain. Correct results are: before after gc_alloc_new.pbc 4.155999 3.836001 gc_alloc_reuse.pbc 16.574 12.318001 gc_generations.pbc 4.025 4.186 gc_header_new.pbc 3.686 4.166 gc_header_reuse.pbc 5.577999 4.345999 gc_waves_headers.pbc 3.815002 3.796001 gc_waves_sizeable_data.pbc 8.383002 7.27 gc_waves_sizeable_headers.pbc 5.668 5.617998 gc_waves_resizeable_data improves by 1.1 gc_header_reuse improves 1.2 gc_alloc_new improves 0.3 gc_alloc_reuse improves 4.2 (as it does for every benchmark) gc_header_new worsens 0.5 gc_waves_resizeable_data improves because it closesly follows the shape of the curve, instead of allocating lots of extra memory all the time. (not sure how closely...depends upon when it runs out of pool memory and copmacts..at the bottom of the curve or at the top). Not really sure how to explain the other results, unfortunately. My imagination has blown it's cover and been exposed for what it is, and it's having some trouble recovering. :) With these new stats, this patch looks like it *does* provide an improvement, and so I think this one is worthwhile (although my comments still stand about looking for an adaptive pool sizing system). Thanks for bearing with me on this, Mike Lambert