Hi Dave,
I ran the tests and found that there are three types of failures. 1. Some tests assume that the default offset is #localOffset. I don't think it's correct, but that's how is it in Trunk. 2. Hashes have changed. This implies that HashedCollections containing DateAndTime instances as key will have to be rehashed. In the base Trunk image there are appear to be no such HashedCollections, but not rehashing such collections will break images with custom packages in them after update. 3. Loss of resolution and strict monotonicity. In Trunk [DateAndTime now < DateAndTime now] is always true. This is possible because DateAndTime has nanosecond resolution, but the source clock only has microsecond resolution, and our machines are so slow that it takes more than a nanosecond to execute the primitive. All these allow us to use the sub-microsecond part of the timestamp to create intermediate strictly monotonic values.
Levente
On Sat, 12 Mar 2016, David T. Lewis wrote:
Hi Levente,
I had not checked the 64-bit image yet, thanks. I did notice from the 32-bit image that the DateAndTime>>= test shows that we might have an opportunity to improve #digitCompare: performance, or maybe think of a better way to do the #= implementation. Your 64-bit results show that it is not a problem for the 64-bit image (because we would be dealing with immediate small integers there).
It's interesting to see that Spur is speeding up overall performance to the point that some primitives are starting to appear relatively slow in comparison. That is very nice problem to have :-)
Dave
On Sat, Mar 12, 2016 at 07:39:14PM +0100, Levente Uzonyi wrote:
Hi David,
I just loaded the code into the latest 64-bit Spur image and VM. Everything works so far, and the overall performance is better as well. For those who care about performance, the speedups are
#testNow->3.01. #testEquals->1.83. #testGreaterThan->1.86. #testLessThan->1.92. #testPrintString->0.85. #testStringAsDateAndTime->1.75.
So, #testPrintString is slighly slower, but everything else is significanlty quicker. I haven't reviewed the code yet, but I'll do.
Levente
On Sat, 12 Mar 2016, David T. Lewis wrote:
On Mon, Mar 07, 2016 at 12:21:38AM -0500, David T. Lewis wrote:
On Sun, May 24, 2015 at 12:36:02PM -0400, David T. Lewis wrote:
UTCDateAndTime is a UTC based implementation of class DateAndTime with one instance variable representing the magnitude of the point in time, and another representing local time zone offset.
I have updated the UTCDateAndTime package to make it loadable in the latest Squeak trunk and Spur.
Has anyone looked at this yet? Any interest?
Dave
A new Monticello repository is at http://www.squeaksource.com/UTCDateAndTime. The home page (with a new SAR) is at http://wiki.squeak.org/squeak/6197.
Starting with an updated trunk image, you can load UTCDateAndTime in two ways:
- Open the http://www.squeaksource.com/UTCDateAndTime repository, and
load the MCZ files in sequence beginning with Chronology-Core-dtl.3.
- In a preferences browser, in category 'updates' set the 'Update URL'
preference to 'http://www.squeaksource.com/UTCDateAndTime', and do world -> help... -> update code from server.
The main objective of UTCDateAndTime is to make DateAndTime conceptually simpler, but a happy side effect is that it is also significantly faster than the old implementation.
Dave