Yes but the ugly bit from memory cache, bandwidth etc point is having to move all the bytes around. I was thinking if only did that every other time or something it might gain you a bit of performance.
However on another note what I've observed with squeak at idle is a lot of time taken to do newspace GC work. Seems we allocate a lot of contexts, which then count towards the 4000 object allocation trigger and we force a GC, which disposes of the contexts on the free chain, which forces us to reallocate them. I'm not sure why we are allocating new contexts all the time, versus finding one on the free context tree, which seems mostly empty.
I did cheat and say, if I allocate one for the context, then decrement the object allocation counter, but that didn't alter the observed behaviour much.
Mmm perhaps I need to poke at it some more to understand what is happening.
On 7-Oct-05, at 1:24 PM, tim Rowledge wrote:
On 7-Oct-05, at 12:59 PM, John M McIntosh wrote:
Mmmm, I have thought about doing a full GC without compacting, that would save time. Anyone consider if that would work?
Well, to do a full gc we have to scan the entire object memory, mark&sweep style, and compacting after that is what gets the dead memory out of the way. Leaving free chunks lying around might not actually kill you but it seems a bit pointless. You're going to have to do it at some point anyway.
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim
-- ======================================================================== === John M. McIntosh johnmci@smalltalkconsulting.com 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== ===