<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">2014-05-26 20:09 GMT+02:00 Chris Muller <span dir="ltr"><<a href="mailto:asqueaker@gmail.com" target="_blank">asqueaker@gmail.com</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Dave, as someone who works with large systems in Squeak, I'm always<br>
interested in _storage efficiency_ as much as execution efficiency.<br>
<br>
DateAndTime, in particular, is a very common domain element with a<br>
high potential for there to be many millions of instances in a given<br>
domain model.<br>
<br>
Apps which have millions of objects with merely a Date attribute can<br>
canonicalize them.<br>
And, apps which have millions of Time objects can canonicalize them.<br>
<br>
But LargeInteger's are not easy to canonicalize (e.g.,<br>
utcMicroseconds). So a database system with millions of DateAndTime's<br>
would have to do _two_ reads for every DateAndTime instance instead of<br>
just one today (because SmallIntegers are immediate, while<br>
LargeIntegers require their own storage buffer).<br>
<br>
One thing I really like about the current implementation of<br>
DateAndTime is how it carefully avoids LargeIntegers by having<br>
large-grained "platforms" to arrive at the current time. e.g., each<br>
'jdn' is a chunk of (1000000*60*60*24) microseconds. Your new<br>
implementation reflects an increase of 86 BILLION utcMicroseconds for<br>
every 1 jdn.<br>
<br>
Small, all-in-memory benchmarks may show faster with the LI, but I'm<br>
concerned that large-scale apps might be significantly impacted in the<br>
opposite way..<br>
<br>
Would it be possible to re-optimize this part of the representation<br>
while still maintaining internal UTC represenation to solve your<br>
concern about daylight-savings?<br>
<br>
Thanks.<br></blockquote><div><br></div><div>That's more or less the Pharo path.<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5"><br>
On Sun, May 25, 2014 at 12:48 PM, David T. Lewis <<a href="mailto:lewis@mail.msen.com">lewis@mail.msen.com</a>> wrote:<br>
> I have been working on a variation of class DateAndTime that replaces its<br>
> instance variables (seconds offset jdn nanos) with two instance variables,<br>
> utcMicroseconds to represent microseconds elapsed since the Posix epoch, and<br>
> localOffsetSeconds to represent the local time zone offset. When instantiating<br>
> the time now, A single call primitiveUtcWithOffset is used to obtain these<br>
> two values atomically as reported by the underlying platform.<br>
><br>
> There are several advantages to this representation of DateAndTime, the most<br>
> important of which is that its magnitude is unambiguous regardless of daylight<br>
> savings transitions in local time zones.<br>
><br>
> This is my attempt to address some historical baggage in Squeak. The VM<br>
> reports time related to the local time zone, and the image attempts to<br>
> convert to UTC (sometimes incorrectly). A UTC based representation makes the<br>
> implementation of time zone tables more straightforward (see for example<br>
> the Olson time zone tables in TimeZoneDatabase on SqueakMap).<br>
><br>
> I am attaching the source code as a SAR file that can be loaded into a fully<br>
> updated Squeak trunk image. The conversion process is slow, so be patient<br>
> if you load it.<br>
><br>
> This can be run on either an intepreter VM or Cog, but if you use Cog, please<br>
> use a version dated June 2013 or later (the VM in the Squeak 4.5 all-in-one<br>
> is fine).<br>
><br>
> I am also attaching a copy of LXTestDateAndTimePerformance, which can be<br>
> used to compare the performance of some basic DateAndTime functions.<br>
><br>
> Performance of the UTC based DateAndTime is generally favorable compared to<br>
> the original. Here is what I see on my system (smaller numbers are better).<br>
><br>
> LXTestDateAndTimePerformance test results using the original Squeak DateAndTime<br>
> on an interpreter VM:<br>
> {<br>
> #testNow->10143 .<br>
> #testEquals->30986 .<br>
> #testGreaterThan->80199 .<br>
> #testLessThan->75912 .<br>
> #testPrintString->10429 .<br>
> #testStringAsDateAndTime->44657<br>
> }<br>
><br>
> LXTestDateAndTimePerformance test results using the new UTC based DateAndTime<br>
> on an interpreter VM:<br>
> {<br>
> #testNow->6423 .<br>
> #testEquals->31625 .<br>
> #testGreaterThan->22999 .<br>
> #testLessThan->18514 .<br>
> #testPrintString->12502 .<br>
> #testStringAsDateAndTime->32912<br>
> }<br>
><br>
> (CC to Brent Pinkney, author of the excellent Squeak Chronology package)<br>
><br>
> Dave<br>
><br>
><br>
><br>
><br>
<br>
</div></div></blockquote></div><br></div></div>