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