DateAndTime is a very good candidate for some slot-tricks, and should probably be a value object. Stephan
Hi, This is indeed something we noticed moving to Pharo3: all our benchmarks fail because of DateAndTime being slower. Since we use Pharo only for development, it's not a showstopper for us, but definitely an issue we are interested to help solving too. Johan On 26 Mar 2014, at 22:53, Stephan Eggermont <stephan@stack.nl> wrote:
DateAndTime is a very good candidate for some slot-tricks, and should probably be a value object.
Stephan
Given the fact that I am using a ton of time series at the moment, I feel that I'll be caught in this as well (Pharo for dev & prod). What about having a look at this through a Google Hangout? Phil On Thu, Mar 27, 2014 at 11:17 AM, Johan Brichau <johan@inceptive.be> wrote:
Hi,
This is indeed something we noticed moving to Pharo3: all our benchmarks fail because of DateAndTime being slower. Since we use Pharo only for development, it's not a showstopper for us, but definitely an issue we are interested to help solving too.
Johan
On 26 Mar 2014, at 22:53, Stephan Eggermont <stephan@stack.nl> wrote:
DateAndTime is a very good candidate for some slot-tricks, and should probably be a value object.
Stephan
On 27 Mar 2014, at 11:17, Johan Brichau <johan@inceptive.be> wrote:
Hi,
This is indeed something we noticed moving to Pharo3: all our benchmarks fail because of DateAndTime being slower.
?? 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.
Since we use Pharo only for development, it's not a showstopper for us, but definitely an issue we are interested to help solving too.
Johan
On 26 Mar 2014, at 22:53, Stephan Eggermont <stephan@stack.nl> wrote:
DateAndTime is a very good candidate for some slot-tricks, and should probably be a value object.
Stephan
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
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
2014-03-27 8:29 GMT-03:00 Sven Van Caekenberghe <sven@stfx.eu>:
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.
I can only tell about Pharo 2, that is the one I'm using. But looking at the code in Pharo 3 it works different.
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.
I spotted this looking at the profiler too. Not in #< but in #=, but both use #asSeconds. Regards! -- Esteban.
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-pe... 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@stfx.eu> wrote:
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
-- Sven Van Caekenberghe Proudly supporting Pharo http://pharo.org http://association.pharo.org http://consortium.pharo.org
On 27 Mar 2014, at 15:17, Sven Van Caekenberghe <sven@stfx.eu> wrote:
My benchmark now runs 40x FASTER than in Pharo 1.4
Wow, very impressive and nice! Thanks for taking care of that. Can't wait to test it here ;-)
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-pe...
I wanted to donate but the link is invalid :p
PS: Half of the funds will go to Camillo for making DateAndTime work in UTC internally ;-)
Yes, this is obviously the major leap and the comments on the performance issue should not overshadow that work! Thank you! Johan
On Thu, Mar 27, 2014 at 3:23 PM, Johan Brichau <johan@inceptive.be> wrote:
On 27 Mar 2014, at 15:17, Sven Van Caekenberghe <sven@stfx.eu> wrote:
My benchmark now runs 40x FASTER than in Pharo 1.4
Wow, very impressive and nice! Thanks for taking care of that. Can't wait to test it here ;-)
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-pe...
I wanted to donate but the link is invalid :p
Yeah, same here :-)
PS: Half of the funds will go to Camillo for making DateAndTime work in UTC internally ;-)
Yes, this is obviously the major leap and the comments on the performance issue should not overshadow that work! Thank you!
Johan
2014-03-27 11:17 GMT-03:00 Sven Van Caekenberghe <sven@stfx.eu>:
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.
Thank you very much Sven. Will the fix be available for Pharo 2 builds as well?
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-pe...
PS: Half of the funds will go to Camillo for making DateAndTime work in UTC internally ;-)
I have some issues transfering big amounts of money overseas.
PS2: I am not sure I am allowed to fix this so close to release, is it a feature or a bug fix ? ;-)
If it's a feature it has to be in the changelog ;-) Thank you again! :) Esteban A. Maringolo
On 27 Mar 2014, at 15:46, Esteban A. Maringolo <emaringolo@gmail.com> wrote:
Will the fix be available for Pharo 2 builds as well?
I knew you were going to ask that, but I don't know. The whole Chronology package was changed quite a lot going from 2.0 -> 3.0 On the other hand, my changes are pretty comprehensible (a couple of methods), somebody could certainly try to backport them - but no guarantees they will work though.
On 27 Mar 2014, at 12:14, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 27 Mar 2014, at 15:46, Esteban A. Maringolo <emaringolo@gmail.com> wrote:
Will the fix be available for Pharo 2 builds as well?
I knew you were going to ask that, but I don't know. The whole Chronology package was changed quite a lot going from 2.0 -> 3.0
On the other hand, my changes are pretty comprehensible (a couple of methods), somebody could certainly try to backport them - but no guarantees they will work though.
pharo3 is at the corner to be out. we are not integrating/backporting changes to pharo2 since⦠well, like 6 months. so no, it will not be there and it will not be integrated. said so⦠anyone can do their own backport and put it for others in a meta repo :) Esteban
2014-03-27 12:14 GMT-03:00 Sven Van Caekenberghe <sven@stfx.eu>:
On 27 Mar 2014, at 15:46, Esteban A. Maringolo <emaringolo@gmail.com> wrote:
Will the fix be available for Pharo 2 builds as well? I knew you were going to ask that, but I don't know.
:)
The whole Chronology package was changed quite a lot going from 2.0 -> 3.0
I know, but this is a "bugfix" not a feature enhancement or is it? :) I know Pharo 3 is uber cool, and way better... but... you'll understand.
On the other hand, my changes are pretty comprehensible (a couple of methods), somebody could certainly try to backport them - but no guarantees they will work though.
I could give them a try. If all tests passes I can contribute the patch back. I have no hurry to fix this. But, but cutting ~40% of response time is a lot in web terms :) Regards,
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@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-pe...
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@stfx.eu> wrote:
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
-- Sven Van Caekenberghe Proudly supporting Pharo http://pharo.org http://association.pharo.org http://consortium.pharo.org
2014-03-27 16:18 GMT-03:00 Johan Brichau <johan@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
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@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@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-pe...
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@stfx.eu> wrote:
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
-- Sven Van Caekenberghe Proudly supporting Pharo http://pharo.org http://association.pharo.org http://consortium.pharo.org
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@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@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@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-pe...
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@stfx.eu> wrote:
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
-- Sven Van Caekenberghe Proudly supporting Pharo http://pharo.org http://association.pharo.org http://consortium.pharo.org
Sven Van Caekenberghe 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-pe... 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 ? ;-)
I would say poor performance is a bug, and if nothing has change in the API, then its not a "new feature" so this should be integrated. Esteban Lorenzano wrote:
pharo3 is at the corner to be out. we are not integrating/backporting changes to pharo2 since⦠well,
like 6 months.
so no, it will not be there and it will not be integrated.
Can you clarify your position that (hopefully) "will not be integrated" refers to just to Pharo 2. cheers -ben
On 27 Mar 2014, at 19:47, Ben Coman <btc@openinworld.com> wrote:
Sven Van Caekenberghe 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-pe... 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 ? ;-)
I would say poor performance is a bug, and if nothing has change in the API, then its not a "new feature" so this should be integrated.
Esteban Lorenzano wrote:
pharo3 is at the corner to be out. we are not integrating/backporting changes to pharo2 since⦠well, like 6 months. so no, it will not be there and it will not be integrated.
Can you clarify your position that (hopefully) "will not be integrated" refers to just to Pharo 2.
it does not need to be integrated to pharo3 because is a backport (that means: is already there) :)
cheers -ben
(I should stop pressing the âsendâ button before saying everything I has to say) On 28 Mar 2014, at 02:09, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On 27 Mar 2014, at 19:47, Ben Coman <btc@openinworld.com> wrote:
Sven Van Caekenberghe 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-pe... 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 ? ;-)
I would say poor performance is a bug, and if nothing has change in the API, then its not a "new feature" so this should be integrated.
it is not :) Bugs are errors that prevents the system to run. If a system runs, even if slow, then is not an error. An improvement on performance is that: an improvement. Ergo, an enhancement. But ofc, nothing prevent s us to integrate an enhancement to the pharo3 version. Just to the release, but that does not means we are not going to change anything in pharo3 after release. We make releases because we need an order, otherwise we are going to continue incorporate improvements until the infinite, with the result of not a single stable version⦠yes, the system we are going to release will not be perfect. Thatâs why we need a pharo4 version (and after that a pharo5, and so onâ¦). If it wouldnât be needed we would be calling this version âpharo, the ultimateâ. and about the change of API: we do not integrate new features not just because the API, is because we cannot be sure about the side effects of a change, even those that can look like a harmless.
Esteban Lorenzano wrote:
pharo3 is at the corner to be out. we are not integrating/backporting changes to pharo2 since⦠well, like 6 months. so no, it will not be there and it will not be integrated.
Can you clarify your position that (hopefully) "will not be integrated" refers to just to Pharo 2.
it does not need to be integrated to pharo3 because is a backport (that means: is already there) :) but⦠if there are more improvements (I did not see the slice), nothing prevents us to integrate it. Just right after the release, or if we are sure (for real) that it will not weak the system (something that I find hard to believe in the case of changes to DateAndTime) :)
Esteban
cheers -ben
Am 28.03.2014 um 09:17 schrieb Johan Brichau <johan@inceptive.be>:
On 28 Mar 2014, at 06:24, Esteban Lorenzano <estebanlm@gmail.com> wrote:
Bugs are errors that prevents the system to run.
<nagging> Some performance problems make the system impossible to work with </nagging>
There are always use cases that make a system painful slow. Bugs? Just sayinâ Norbert
Hi johan Please let us know because I would be in favor of integrating such speed up if your system fully work. stef On 28 Mar 2014, at 09:17, Johan Brichau <johan@inceptive.be> wrote:
On 28 Mar 2014, at 06:24, Esteban Lorenzano <estebanlm@gmail.com> wrote:
Bugs are errors that prevents the system to run.
<nagging> Some performance problems make the system impossible to work with </nagging>
Anyway, going to check in Sven's changes today.
cheers Johan
Hi all, With Sven's fixes loaded, our model unit tests are all running fine. The benchmarks indicate the same speed as in 1.4. This is really great! I'm still running the entire suite of tests but that will take a while to complete. But essential datetime bugs should have been spotted already. Great work Sven! I think it's worth integrating. If not, we will definitely work with this patched version. Johan On 28 Mar 2014, at 13:36, Pharo4Stef <pharo4Stef@free.fr> wrote:
Hi johan
Please let us know because I would be in favor of integrating such speed up if your system fully work.
stef
On 28 Mar 2014, at 09:17, Johan Brichau <johan@inceptive.be> wrote:
On 28 Mar 2014, at 06:24, Esteban Lorenzano <estebanlm@gmail.com> wrote:
Bugs are errors that prevents the system to run.
<nagging> Some performance problems make the system impossible to work with </nagging>
Anyway, going to check in Sven's changes today.
cheers Johan
Looks like a lot of people are going to be running patched versions if the release goes without some enhancements. What about a ConfigurationOfPharo30EnhancementsPackThatWereNotIntegratedForSomeSurelyVeryValidReason ? (Let's make the name shorter but you get the idea). Phil On Fri, Mar 28, 2014 at 4:02 PM, Johan Brichau <johan@inceptive.be> wrote:
Hi all,
With Sven's fixes loaded, our model unit tests are all running fine. The benchmarks indicate the same speed as in 1.4. This is really great! I'm still running the entire suite of tests but that will take a while to complete. But essential datetime bugs should have been spotted already.
Great work Sven! I think it's worth integrating. If not, we will definitely work with this patched version.
Johan
On 28 Mar 2014, at 13:36, Pharo4Stef <pharo4Stef@free.fr> wrote:
Hi johan
Please let us know because I would be in favor of integrating such speed up if your system fully work.
stef
On 28 Mar 2014, at 09:17, Johan Brichau <johan@inceptive.be> wrote:
On 28 Mar 2014, at 06:24, Esteban Lorenzano <estebanlm@gmail.com>
wrote:
Bugs are errors that prevents the system to run.
<nagging> Some performance problems make the system impossible to work with </nagging>
Anyway, going to check in Sven's changes today.
cheers Johan
Am 28.03.2014 um 16:56 schrieb phil@highoctane.be:
Looks like a lot of people are going to be running patched versions if the release goes without some enhancements.
That is the road to never have a release.
What about a ConfigurationOfPharo30EnhancementsPackThatWereNotIntegratedForSomeSurelyVeryValidReason ?
(Let's make the name shorter but you get the idea).
It is easy. It is called pharo 3.1 or pharo 4.0. The rule is: Donât change the current release being in freeze. Release it, change then everything you wanted in the next step and make sure you can release the next version pretty soon. IMHO the best solution to this kind of problems is to have small iterations. Norbert
On Fri, Mar 28, 2014 at 4:02 PM, Johan Brichau <johan@inceptive.be> wrote: Hi all,
With Sven's fixes loaded, our model unit tests are all running fine. The benchmarks indicate the same speed as in 1.4. This is really great! I'm still running the entire suite of tests but that will take a while to complete. But essential datetime bugs should have been spotted already.
Great work Sven! I think it's worth integrating. If not, we will definitely work with this patched version.
Johan
On 28 Mar 2014, at 13:36, Pharo4Stef <pharo4Stef@free.fr> wrote:
Hi johan
Please let us know because I would be in favor of integrating such speed up if your system fully work.
stef
On 28 Mar 2014, at 09:17, Johan Brichau <johan@inceptive.be> wrote:
On 28 Mar 2014, at 06:24, Esteban Lorenzano <estebanlm@gmail.com> wrote:
Bugs are errors that prevents the system to run.
<nagging> Some performance problems make the system impossible to work with </nagging>
Anyway, going to check in Sven's changes today.
cheers Johan
It is easy. It is called pharo 3.1 or pharo 4.0. The rule is: Donât change the current release being in freeze. Release it, change then everything you wanted in the next step and make sure you can release the next version pretty soon. IMHO the best solution to this kind of problems is to have small iterations.
Yes I like your idea. We can do a 3.1. May be this is an indication that we should start a 4.0alpha? Stef
On Fri, Mar 28, 2014 at 8:17 PM, Ben Coman <btc@openinworld.com> wrote:
phil@highoctane.be wrote:
Looks like a lot of people are going to be running patched versions if the release goes without some enhancements.
What about a ConfigurationOfPharo30EnhancementsPackThatWereNotIntegratedForSomeSurelyVeryValidReason ?
(Let's make the name shorter but you get the idea).
Phil
I wonder if it would be more or less effort to operate a "hot fix" facility between releases. By this I mean, after Pharo 3 release all slices fixing Pharo 3 bugs are based off the static release. This might have the advantages that: * Users get to select the bug fixes important to them * Ergo, users can can avoid bug fixes not relevant to them that might have unintended consequences in production. * Bug fixes don't go stale when fixed in the released Pharo 3 but the Pharo 3 builds have progressed a lot. * Users don't have to decide between waiting for a the next Pharo 3 minor-release, or tracking a moving target with continued evolution of "latest" Pharo 3 after release. * The part of the community that wants longer term support for systems in production could take a greater role in maintaining Pharo 3, while the core focus moves on to Pharo 4.
A simple process might be tagging such resolved issues in Fogbugz as as 3.0-hotfix. Alternatively a tool like the Configuration Browser might list them in image. That tool could be installed from the Configuration Browser as ConfigurationOfHotfix.
The downside would be more difficulty in packaging hotfixes together for a minor-release. However over time hotfixes might be consolidated into other hotfixes, and the greatest of these becomes the basis for the minor-release.
Just a passing thought. cheers, Ben
A hotfix tool would be the other side of the Kommiter coin. So, Hotfixer?
With a UI showing slices for which the status in FogBugz would be "hotfix30" Or a list of HOTFIX- in Pharo/Pharo30Hotfix/ in Smalltalkhub. Ah, let's make something for getting the ball rolling: http://www.smalltalkhub.com/#!/~Pharo/Pharo3Hotfix So,a HOTFIX shall possibly combine SLICEs or packages in a proper loading order and postscripts (like the one of Ben). I am currently writing some package loading code for my own use, this would be a nice opportunity for me to do a Spec based tool. Wanna join forces, people? Phil
On Fri, Mar 28, 2014 at 4:02 PM, Johan Brichau <johan@inceptive.be> wrote:
Hi all,
With Sven's fixes loaded, our model unit tests are all running fine. The benchmarks indicate the same speed as in 1.4. This is really great! I'm still running the entire suite of tests but that will take a while to complete. But essential datetime bugs should have been spotted already.
Great work Sven! I think it's worth integrating. If not, we will definitely work with this patched version.
Johan
On 28 Mar 2014, at 13:36, Pharo4Stef <pharo4Stef@free.fr> wrote:
Hi johan
Please let us know because I would be in favor of integrating such speed up if your system fully work.
stef
On 28 Mar 2014, at 09:17, Johan Brichau <johan@inceptive.be> wrote:
On 28 Mar 2014, at 06:24, Esteban Lorenzano <estebanlm@gmail.com>
wrote:
Bugs are errors that prevents the system to run.
<nagging> Some performance problems make the system impossible to work with </nagging>
Anyway, going to check in Sven's changes today.
cheers Johan
2014-03-28 5:24 GMT+00:00 Esteban Lorenzano <estebanlm@gmail.com>:
Bugs are errors that prevents the system to run. If a system runs, even if slow, then is not an error.
One could argue that bugs are defects that cause unintended behaviour (including not operating at all). Given that definition, and assuming that poor performance is not intended, slowness may well qualify as a bug. But if someone points me to a formal definition of bug that precludes my interpretation, I´ll shut up until I find something else to rant about :) Cheers, Sergi
Excellent! Thanks for all this good and proactive energy. Stef
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-pe...
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@stfx.eu> wrote:
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
-- Sven Van Caekenberghe Proudly supporting Pharo http://pharo.org http://association.pharo.org http://consortium.pharo.org
participants (10)
-
Ben Coman -
Esteban A. Maringolo -
Esteban Lorenzano -
Johan Brichau -
Norbert Hartl -
Pharo4Stef -
phil＠highoctane.be -
Sergi Reyner -
Stephan Eggermont -
Sven Van Caekenberghe