On 27 Mar 2014, at 11:55, Johan Brichau <[email protected]> wrote:
> On 27 Mar 2014, at 11:50, Sven Van Caekenberghe <[email protected]> wrote:
>
>> It is slow(er) in 2 and fast(er) in 3, according to this discussion and my
>> reading of the code. If you see the inverse, than please provide some
>> details.
>
> We come from Pharo 1.4, where our timing benchmarks that use a lot of
> DateAndTime operations run 4x faster (in Gemstone too).
> It is indeed faster in 3 than in 2. (I believe because of a wait in de
> DateAndTime creation that has to do with clock precision).
>
> Johan
An x4 (400%) slowdown sounds like an unacceptable regression to me.
Could you maybe provide some benchmark ?
I did a quick one (in Pharo 3):
[
| timestamps |
timestamps := Array streamContents: [ :out |
1024 timesRepeat: [ out nextPut: (DateAndTime now - (60*60*24*265)
atRandom seconds) ] ].
64 timesRepeat: [ timestamps sorted ].
timestamps sort.
timestamps collect: [ :each | timestamps includes: each ] ] timeToRun.
=> "0:00:00:09.491"
In 1.4, this is indeed about 40 times faster:
[
| timestamps |
timestamps := Array streamContents: [ :out |
1024 timesRepeat: [ out nextPut: (DateAndTime now - (60*60*24*265)
atRandom seconds) ] ].
64 timesRepeat: [ timestamps sorted ].
timestamps sort.
timestamps collect: [ :each | timestamps includes: each ] ] timeToRun
milliSeconds.
=> "0:00:00:00.228"
For this test, ZTimestamp is 100 times faster:
[
| timestamps |
timestamps := Array streamContents: [ :out |
1024 timesRepeat: [ out nextPut: (ZTimestamp now - (60*60*24*265)
atRandom seconds) ] ].
64 timesRepeat: [ timestamps sorted ].
timestamps sort.
timestamps collect: [ :each | timestamps includes: each ] ] timeToRun.
=> "0:00:00:00.07"
Looking at this with the Time Profiler, I see that DateAndTime>>#asSeconds
(used in #<) takes 95% of the time. I am pretty sure we can fix this. I'll make
an issue and slice later on.
Sven
