- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] DateAndTime>>#= slow?

by Sven Van Caekenberghe

But if you have a reasonably recent 3.0 image somewhere, you can try merging as well. If all is good you see only 3 changed methods (#- #+ and #<). Even if you see more changes, you could try only importing those. On 27 Mar 2014, at 23:13, Stephan Eggermont <stephan(a)stack.nl> wrote: > Esteban wrote >> How do I test it? >> Do I have to download a whole new 3.0 image? > > Normal way to test is to download latest 3.0 image > and run it (on latest vm). > Open monticello, open Pharo30Inbox, > Type the issue number to find the slice > and merge it to see changes. > > Stephan >

March 27, 2014

Re: [Pharo-dev] Smalltalkhub & API

by Tobias Pape

On 27.03.2014, at 21:36, Stephan Eggermont <stephan(a)stack.nl> wrote: > Hi Phil, > > Did you take a look at a smalltalkhub image > https://ci.inria.fr/pharo-contribution/job/SmalltalkHub/ > The Hub package provides a starting point. I dl'ed the latest that was tagged 2.0, but it comes just with the configuration loaded. Trying to load that eventually kills the VMâ¦ Best -Tobias

March 27, 2014

Re: [Pharo-dev] DateAndTime>>#= slow?

by Stephan Eggermont

Esteban wrote >How do I test it? >Do I have to download a whole new 3.0 image? Normal way to test is to download latest 3.0 image and run it (on latest vm). Open monticello, open Pharo30Inbox, Type the issue number to find the slice and merge it to see changes. Stephan

March 27, 2014

Re: [Pharo-dev] DateAndTime>>#= slow?

by Esteban A. Maringolo

How do I test it? Do I have to download a whole new 3.0 image? Regards! Esteban A. Maringolo 2014-03-27 18:42 GMT-03:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > Johan, Esteban, > > Here is the first patch: > > https://pharo.fogbugz.com/f/cases/13145/Speed-Up-DateAndTime-Arithmetic > > The other things that I tried (caching #epoch and switching the #localTimeZone to an #asFixedTimeZone variant) are now almost irrelevant since they no longer appear on the critical path while time profiling. > > Please let me know how it goes. > > Sven > > On 27 Mar 2014, at 20:18, Johan Brichau <johan(a)inceptive.be> wrote: > >> Sven, >> >> FYI, if you have the slice, I can run all our tests against it. >> We do just a little bit of things with DateAndTime in a planning app :-) so potential issues might be exposed. >> >> Johan >> >> On 27 Mar 2014, at 15:17, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >>> Umbrella issue: >>> >>> https://pharo.fogbugz.com/f/cases/13139/Speed-Regressions-in-DateAndTime >>> >>> I rewrote (and simplified) DateAndTime>>#+ #- #= >>> I added caching for #epoch >>> I switched the localTimeZone to an #asFixedTimeZone variant >>> >>> My benchmark now runs 40x FASTER than in Pharo 1.4 >>> >>> All Chronology tests remain green. >>> >>> I will upload slices when the funding goal of 1,000,000 USD is reached on https://www.kickstarter.com/projects/1003214829/improve-pharo-dateandtime-p… >>> >>> PS: Half of the funds will go to Camillo for making DateAndTime work in UTC internally ;-) >>> >>> PS2: I am not sure I am allowed to fix this so close to release, is it a feature or a bug fix ? ;-) >>> >>> On 27 Mar 2014, at 12:29, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>> >>>> >>>> On 27 Mar 2014, at 11:55, Johan Brichau <johan(a)inceptive.be> wrote: >>>> >>>>> On 27 Mar 2014, at 11:50, Sven Van Caekenberghe <sven(a)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 >>>> >>> >>> >>> >>> -- >>> Sven Van Caekenberghe >>> Proudly supporting Pharo >>> http://pharo.org >>> http://association.pharo.org >>> http://consortium.pharo.org >>> >>> >>> >>> >>> >> >> > >

March 27, 2014

Re: [Pharo-dev] DateAndTime>>#= slow?

by Sven Van Caekenberghe

Johan, Esteban, Here is the first patch: https://pharo.fogbugz.com/f/cases/13145/Speed-Up-DateAndTime-Arithmetic The other things that I tried (caching #epoch and switching the #localTimeZone to an #asFixedTimeZone variant) are now almost irrelevant since they no longer appear on the critical path while time profiling. Please let me know how it goes. Sven On 27 Mar 2014, at 20:18, Johan Brichau <johan(a)inceptive.be> wrote: > Sven, > > FYI, if you have the slice, I can run all our tests against it. > We do just a little bit of things with DateAndTime in a planning app :-) so potential issues might be exposed. > > Johan > > On 27 Mar 2014, at 15:17, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> Umbrella issue: >> >> https://pharo.fogbugz.com/f/cases/13139/Speed-Regressions-in-DateAndTime >> >> I rewrote (and simplified) DateAndTime>>#+ #- #= >> I added caching for #epoch >> I switched the localTimeZone to an #asFixedTimeZone variant >> >> My benchmark now runs 40x FASTER than in Pharo 1.4 >> >> All Chronology tests remain green. >> >> I will upload slices when the funding goal of 1,000,000 USD is reached on https://www.kickstarter.com/projects/1003214829/improve-pharo-dateandtime-p… >> >> PS: Half of the funds will go to Camillo for making DateAndTime work in UTC internally ;-) >> >> PS2: I am not sure I am allowed to fix this so close to release, is it a feature or a bug fix ? ;-) >> >> On 27 Mar 2014, at 12:29, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >>> >>> On 27 Mar 2014, at 11:55, Johan Brichau <johan(a)inceptive.be> wrote: >>> >>>> On 27 Mar 2014, at 11:50, Sven Van Caekenberghe <sven(a)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 >>> >> >> >> >> -- >> Sven Van Caekenberghe >> Proudly supporting Pharo >> http://pharo.org >> http://association.pharo.org >> http://consortium.pharo.org >> >> >> >> >> > >

March 27, 2014

Re: [Pharo-dev] DateAndTime>>#= slow?

by Stephan Eggermont

Sven wrote: >PS2: I am not sure I am allowed to fix this so close to release, is it a feature or a bug fix ? ;-) Donât worry, if you look at the slope of our issue burndown chart you might notice that we need to change directions to get closer to releaseâ¦ Stephan

March 27, 2014

Re: [Pharo-dev] Smalltalkhub & API

by phil＠highoctane.be

Ah, good. I'll look at that. Thx

March 27, 2014

Re: [Pharo-dev] Smalltalkhub & API

by Stephan Eggermont

Hi Phil, Did you take a look at a smalltalkhub image https://ci.inria.fr/pharo-contribution/job/SmalltalkHub/ The Hub package provides a starting point. Stephan

March 27, 2014

Re: [Pharo-dev] DateAndTime>>#= slow?

by Esteban A. Maringolo

2014-03-27 16:18 GMT-03:00 Johan Brichau <johan(a)inceptive.be>: > Sven, > > FYI, if you have the slice, I can run all our tests against it. > We do just a little bit of things with DateAndTime in a planning app :-) so potential issues might be exposed. My app also deals with schedules, that's how I found this :) But I'm sure I don't have as many tests as you do. o.O Esteban A. Maringolo

March 27, 2014

Re: [Pharo-dev] DateAndTime>>#= slow?

by Johan Brichau

Sven, FYI, if you have the slice, I can run all our tests against it. We do just a little bit of things with DateAndTime in a planning app :-) so potential issues might be exposed. Johan On 27 Mar 2014, at 15:17, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Umbrella issue: > > https://pharo.fogbugz.com/f/cases/13139/Speed-Regressions-in-DateAndTime > > I rewrote (and simplified) DateAndTime>>#+ #- #= > I added caching for #epoch > I switched the localTimeZone to an #asFixedTimeZone variant > > My benchmark now runs 40x FASTER than in Pharo 1.4 > > All Chronology tests remain green. > > I will upload slices when the funding goal of 1,000,000 USD is reached on https://www.kickstarter.com/projects/1003214829/improve-pharo-dateandtime-p… > > PS: Half of the funds will go to Camillo for making DateAndTime work in UTC internally ;-) > > PS2: I am not sure I am allowed to fix this so close to release, is it a feature or a bug fix ? ;-) > > On 27 Mar 2014, at 12:29, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> >> On 27 Mar 2014, at 11:55, Johan Brichau <johan(a)inceptive.be> wrote: >> >>> On 27 Mar 2014, at 11:50, Sven Van Caekenberghe <sven(a)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 >> > > > > -- > Sven Van Caekenberghe > Proudly supporting Pharo > http://pharo.org > http://association.pharo.org > http://consortium.pharo.org > > > > >

March 27, 2014