About 2950 ms.
A fine tuning can make a big difference !
I am impressed.

Joseph

----- Original Message ----- 
From: "Andreas Raab" <andreas.raab at gmx.de>
To: "The general-purpose Squeak developers list" 
<squeak-dev at lists.squeakfoundation.org>
Sent: Thursday, December 02, 2004 11:21 PM
Subject: Re: Object turnover.


>> Compared to 1 second, it is not so fast ... (or did I make a mistake ?)
>
> You didn't make a mistake but you did take the code at face value where I 
> told you not to ;-) So let's optimize this a little for Squeak:
>
> Baseline code:
> --------------
> Time millisecondsToRun: [
> seq := OrderedCollection new.
> 1000 timesRepeat: [seq add: (Point x: 0 y: 0)].
> 20000 timesRepeat: [1 to: 1000 do: [:n | seq at: n put: (Point x: 0 y: 
> 0)]]]
>
> This runs in 38,923 msecs on my machine.
>
> Use @ instead of x:y:
> ---------------------
> First thing to do is to create points using the "@" operator - this 
> operator is inlined and a lot faster than sending x:y: without actually 
> adding anything to the GC overhead.
>
> Time millisecondsToRun: [
> seq := OrderedCollection new.
> 1000 timesRepeat: [seq add: 0 at 0].
> 20000 timesRepeat: [1 to: 1000 do: [:n | seq at: n put: 0 at 0]]]
>
> This runs in about 15,580 ms on my machine which is less than half of the 
> original code.
>
> Use Array instead of OrderedCollection
> --------------------------------------
> The second thing is to use an Array instead of an OrderedCollection. 
> OrderedCollection adds a number of extra indirections and messages which 
> (compared to VW) are very slow in Squeak.
>
> Time millisecondsToRun: [
> seq := Array new: 1000.
> 1 to: 1000 do:[:i| seq at: i put: 0 at 0].
> 20000 timesRepeat: [1 to: 1000 do: [:n | seq at: n put: 0 at 0]]]
>
> This runs in about 7,155 ms which is about 5.5 times faster than your 
> original code, so hopefully you'll see something in the 3.5 secs range.
>
> If you are curious about what I've done in the above it's merely to remove 
> any message sends I could - this is an area where VW is significantly 
> faster than Squeak and one which has almost no impact on the GC behavior 
> of the code. In terms of GC behavior the last version is as good as the 
> first.
>
>
> Cheers,
>  - Andreas
>
> ----- Original Message ----- 
> From: "Joseph Frippiat" <joseph.frippiat at skynet.be>
> To: "The general-purpose Squeak developers list" 
> <squeak-dev at lists.squeakfoundation.org>
> Sent: Thursday, December 02, 2004 11:08 PM
> Subject: Re: Object turnover.
>
>
>> Hi,
>>
>> This is what I tried on Squeak 3.7 :
>>
>> Time millisecondsToRun: [
>> seq := OrderedCollection new.
>> 1000 timesRepeat: [seq add: (Point x: 0 y: 0)].
>> 20000 timesRepeat: [1 to: 1000 do: [:n | seq at: n put: (Point x: 0 y: 
>> 0)]]]
>>
>> I repaced Point zero with Point x: 0 y: 0 (I don't know VisualWorks).
>>
>> The result is near 18450 on a Pentium 4, 3.40GHz HT.
>>
>> Compared to 1 second, it is not so fast ... (or did I make a mistake ?)
>>
>> Joseph
>>
>>
>> ----- Original Message ----- 
>> From: "Andreas Raab" <andreas.raab at gmx.de>
>> To: "The general-purpose Squeak developers list" 
>> <squeak-dev at lists.squeakfoundation.org>
>> Sent: Thursday, December 02, 2004 9:23 PM
>> Subject: Re: Object turnover.
>>
>>
>>> An interesting read here is the following:
>>>
>>> http://www.cincomsmalltalk.com/userblogs/travis/blogView?showComments=true&entry=3277556678
>>>
>>> Squeak isn't quite as fast if you run the benchmarks (though for largely 
>>> non-GC related reasons) but by and large this should get you a feeling 
>>> that dealing with lots and lots of objects (and cleaning up afterwards) 
>>> is something that these systems (incl. Squeak) have been specifically 
>>> designed for. It is really, REALLY fast.
>>>
>>> Cheers,
>>>  - Andreas
>>>
>>> ----- Original Message ----- 
>>> From: "Tim Rowledge" <tim at sumeru.stanford.edu>
>>> To: <squeak-dev at lists.squeakfoundation.org>
>>> Sent: Thursday, December 02, 2004 8:24 PM
>>> Subject: Re: Object turnover.
>>>
>>>
>>>> Ryan Zerby <tahognome at gmail.com> wrote:
>>>>
>>>>> Should I worry about having a program that makes a large number of
>>>>> temporary objects?
>>>> Not in the sense of having to worry about the system not being able to
>>>> cope. VM implementors over the ages have done your worrying for you!
>>>>
>>>> However, it is often the case that a little fiddling with algorithms
>>>> can improve things; it's time for you to start using the
>>>> TimeProfileBrowser to see where your time goes. Look it up in the
>>>> browser and start playing.
>>>>
>>>>> planet position: (Point r: rho degree: theta) + self center.
>>>>
>>>>>
>>>>> This creates a lot of points that get discarded on the next iteration
>>>>> of step.
>>>> No great problem; the gc will recycle them almost immediately. The time
>>>> 'wasted' is simply that you might be creating them unneccessarily, say
>>>> if the algorithm can be squeezed a bit.
>>>>
>>>> If you have a large number of planets in mind you might even benefit
>>>> from the sort of low down underhanded cleverness that Yoshiki has
>>>> recently used to do very fast array processing in the cellular automata
>>>> morphs. By putting the coordinates into FloatArrays it is possible to
>>>> get thousands of cells bouncing around; at least on machines with
>>>> floatingpoint hardware like I don't have :-(
>>>>
>>>>
>>>> tim
>>>> --
>>>> Tim Rowledge, tim at sumeru.stanford.edu, http://sumeru.stanford.edu/tim
>>>> The program is absolutely right; therefore the computer must be wrong.
>>>>
>>>
>>>
>>>
>>
>>
>
>
>