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 at rowledge.org; http://www.rowledge.org/tim
>
>
>
>
>

--
======================================================================== 
===
John M. McIntosh <johnmci at smalltalkconsulting.com> 1-800-477-2659
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
======================================================================== 
===