> 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.
>>>
>>
>>
>>
>
>