[Vm-dev] Re: A trick to speedup #become: (but not becomeForward:)

Andreas Raab andreas.raab at gmx.de
Sun Jul 31 15:42:26 UTC 2011

On 7/31/2011 17:06, Igor Stasenko wrote:
> On 31 July 2011 10:32, Andreas Raab<andreas.raab at gmx.de>  wrote:
>> On 7/31/2011 6:56, Igor Stasenko wrote:
>>> And it works! All become tests are green.
>>> See attached for VM and image side code.
>> Good idea. But your benchmark is a little off:
>>> Now most interesting thing. How much speed we gain?
>>> Before:
>>> | x y |
>>> x := 'ab' copy.
>>> y := 'cd' copy.
>>> [ 100 timesRepeat: [ x become: y ] ] timeToRun
>> x and y should be young in the above and the performance of #become should
>> be much faster than when they are old. To wit:
>> [ 100 timesRepeat: [ 'ab' copy become: 'cd' copy ] ] timeToRun
>> =>  36
>> | x y |
>> x := 'ab' copy.
>> y := 'cd' copy.
>> Smalltalk garbageCollect. "make x and y old"
>> [ 100 timesRepeat: [ x become: y ] ] timeToRun
>> =>    1248
>> So I'm not sure how valid your benchmark really is.
> It is valid, because i comparing performance of using same method (#become:)
> before and after changes.

It's important to measure these things correctly, otherwise one cannot 
repeat your results. When executing the code as presented, I was 
entirely unable to recreate your results, because the code all but 
guarantees that x and y will be young. I just wanted to point that out 
to people who like to measure such things.

> But of course, a heap-scanning become heavily depends where object(s)
> located in young space or old one,
> and performs much faster if it needs to scan only new space.
> But memory-swapping become apparently having no such dependency. It
> only depends on object size to be swapped.
> So, okay.. for cases, when both objects residing in new space, it will
> be not hundrends of thousands times faster but only tens thousands
> times. :)
> Which is still a huge advantage.

Yes. And that's why I said that this is indeed a good idea if it can be 
made to work properly. I would expect that there is a need to ensure 
that the formats of the objects are the same, no? Otherwise #becoming a 
CompiledMethod into an Array could have "interesting" consequences :-)

   - Andreas

More information about the Vm-dev mailing list