On Sat, Apr 19, 2014 at 01:31:43PM -0700, Paul DeBruicker wrote:
> You probably looked at this but Chronos, in the unadulterated Squeak 4.4
> all-in-one, is ~2.5x faster than DateAndTime.  E.g.
> 
> [100000 timesRepeat: [Timepoint now]] timeToRun 387
> 
> [100000 timesRepeat: [DateAndTime now]] timeToRun  971
> 

Actually, this is one area where the experimental DateAndTime version
gives a substantial improvement.

Squeak trunk:
  [1000000 timesRepeat: [DateAndTime now]] timeToRun ==> 2448

Modified version with UTC based DateAndTime:
  [1000000 timesRepeat: [DateAndTime now]] timeToRun ==> 1264

But it turns out that most uses of DateAndTime involve conversion to and
from strings, so in practice most the time time gets eaten up in parsing
and in numeric conversions, regardless of the underlyingkrepresentation
of the time magnitude.

The single UTC variable approach has some advantage in overall simplicity,
but that seems to be partly offset by efficiencies of small integer
computation in the current DateAndTime approach.

Dave

> 
> Maybe there are some ideas worth taking in there.  
> 
> 
> 
> The Chronos repo is here:
> 
> MCHttpRepository
> 	location: 'http://smalltalkhub.com/mc/Chronos/Chronos/main'
> 	user: ''
> 	password: ''
> 
> You can load it in a workspace with
> 
> ConfigurationOfChronos load
> 
> 
> Assuming you have metacello loaded.  
> 
> 
> 
> 
> 
> 
> 
> David T. Lewis wrote
> > I have been experimenting with a new implementation of DateAndTime based
> > on a UTC magnitude. In this implementation, the instance variables jdn,
> > seconds, and nanos are replaced with a single utcMicroseconds, and the
> > offset (a Duration) is replaced by localOffsetSeconds (an integer). The
> > UTC magnitude and offset are provided directly by primitiveUtcWithOffset
> > when doing DateAndTime now.
> > 
> > I had hoped to achieve a sigificant performance advantage with this
> > implementation, and while it does improve performance, I am only seeing
> > about a 10% improvement overall, which is considerably less than I had
> > hoped.
> > Nevertheless, it is indeed faster, and implemention does have some
> > interesting
> > characteristics.
> > 
> > The utcMicroseconds magnitude is in units of microseconds, but it is not
> > required to be an integer and may represent time to any precision. In
> > practice,
> > values are integral unless the instance is explicitly created with a
> > nanosecond
> > value.
> > 
> > New instances created by "DateAndTime now" will have the correct time zone
> > offset as provided by the operating system platform, and their magnitude
> > is
> > set to a UTC value the precision provided by the platform.
> > 
> > New instances created by other constructors use TimeZone default, which is
> > problematic given that the time zone in Squeak may or may not match the
> > (presumably correct) values provided by the operating system.
> > 
> > Instances of DateAndTime are (at the moment) considered equal if their
> > magnitudes
> > are the same, independent of the time zone offset. This makes sense when
> > thinking
> > of them as magnitudes (DateAndTime is a Magnitude), but saying that two
> > instances
> > with different local offsets are equal might be wrong in other contexts.
> > 
> > The localOffsetSeconds is used for displaying the date and time, and is
> > not
> > related to magnitude. Thus a DateAndTime is both a magnitude (UTC time)
> > and a
> > formatter (use the offset to show the magnitude in the context of a local
> > time zone).
> > 
> > Dave
> 
> 
> 
> 
> 
> --
> View this message in context: http://forum.world.st/open-paren-brace-bracket-tp4755162p4755475.html
> Sent from the Squeak - Dev mailing list archive at Nabble.com.