On 27 Mar 2014, at 19:47, Ben Coman <[email protected]> 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-performance > > 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 > > >
