On 27 Mar 2014, at 11:55, Johan Brichau <johan@inceptive.be> wrote:
On 27 Mar 2014, at 11:50, Sven Van Caekenberghe <sven@stfx.eu> 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