On Fri, Jan 11, 2019 at 11:29:53AM -0800, Eliot Miranda wrote:
> Hi David,
> 
> > On Jan 11, 2019, at 11:15 AM, David T. Lewis <lewis at mail.msen.com> wrote:
> > 
> >> On Fri, Jan 11, 2019 at 09:43:03AM -0800, Eliot Miranda wrote:
> >> 
> >> 
> >>> On Jan 10, 2019, at 6:20 PM, David T. Lewis <lewis at mail.msen.com> wrote:
> >>> 
> >>> This is a good optimization. After taking a brief look at the performance
> >>> numbers, I can see a significant (almost 2X) improvement in DateAndTime>>asTime.
> >> 
> >> In 32-bit or 64-bit?
> > 
> > This is on 64-bit, I did not check 32-bit.
> 
> Can you post the test?  I???d like to measure 32-bits where the difference should be larger.

Ugh, I cannot even reproduce my own results, so now I am not sure if there
is a performance difference or not.

I was comparing performance on a 64-bit Spur image with Chronology-Core-eem.22
loaded (optimized version), versus the same image with Chronology-Core-ul.21
loaded (no optimization).

I started by running this (from the http://www.squeaksource.com/UTCDateAndTime
repository):

  LXTestDateAndTimePerformance new test

Then I looked for senders of #asSeconds and tried a couple of those in big
loops. For #asTime, I compared the two Chronolgy-Core versions using this:

  Time millisecondsToRun: [ 100000000 timesRepeat: [DateAndTime now asTime]]

I thought that I was seeing a big performance difference, but I may have been
getting fooled by jit warmup times and so forth. It was just a quick test,
and I did not take the time to make sure it was reproducible.

Obviously these are very naive tests. I thought I was seeing a big performance
difference in the #asTime loop, but now I am not sure. 

Dave