TimeForSpeed

Hi!

Just posted this ENH on Mantis making "DateAndTime now" 6 times faster
(and lots, lots more):

        http://bugs.impara.de/view.php?id=4669

...enjoy. And please review.

regards, Göran

[hidden email] schrieb:
> Hi!
>
> Just posted this ENH on Mantis making "DateAndTime now" 6 times faster
> (and lots, lots more):
>
> http://bugs.impara.de/view.php?id=4669
>
> ...enjoy. And please review.

Great that someone is looking into this!

There are other gross inefficiencies in there, like that every Date
instance stores a duration with nano-second precision. See

http://article.gmane.org/gmane.comp.lang.smalltalk.squeak.general/100427

- Bert -

Hi!

Bert Freudenberg <[hidden email]> wrote:
Right. I haven't looked into all this enough to give any judgement on
the design - I just did "behaviour preserving refactorings" to get
speed. It would be nice if someone could summarize all Time related
classes and when to use which one. There is plenty of them these days.
:)

For example, Date as you mention seems IMHO also like it still could be
stored as a julian day number. A "Date beast" with duration etc seems
like it probably could be called a Day instead. A Date does not in my
mind represent a "specific historic period", but I am no expert of
course.

regards, Göran

PS. We also use the Timezone stuff from David Lewis and that also ties
into this using class PointInTime etc. Phew. One thing we found is that
David added a small "daemon" process that keeps track of "now" and that
can very quickly give back an instance. But it wasn't hooked into the
general machinery so it was just sitting there. :) We hooked it in and
it seems to work - though I am unsure if it turned out faster than the
ENH I posted - I don't think so.

Hi,

From the Mantis issue:
I am nominally responsible for the Chronology package since I wrote it :)
 
I have tested and reviewed this change. All tests pass in 3.8.1 (6744).
 
I would also encourage this enhancement to include Dan Ingall's modificaton
which significantly speeds up printing a DateAndTime instance.

All tests work with both enhancements.
I have attached my cleanup of Dan's code to this issue.
 
     suite := TestSuite new name: 'Chronology Tests'.
     (SystemOrganization superclassOrder: #'Kernel-Chronology-Tests')
         do: [ :tc | tc addToSuiteFromSelectors: suite ].
     suite run.
 
RESULT: 420 run, 420 passes, 0 expected failures, 0 failures, 0 errors...
 
I strongly encourage both changesets to be approved.

---------------------------------------------------------------------------------------------------------------
> It would be nice if someone could summarize all Time related
> classes and when to use which one. There is plenty of them these days.

I developed the Chronology class to precisely solve the problem of many Time classes.
If you read the original wiki page (http://minnow.cc.gatech.edu/squeak/1871) I refer to
my experience with Java/J++ where there were 6 different class libraries to choose from.

I added the support for nano second precision precisely to future-proof the design.

> For example, Date as you mention seems IMHO also like it still could be
> stored as a julian day number. A "Date beast" with duration etc seems
> like it probably could be called a Day instead.

Perhaps, but a Date definately starts at midnight and ends 86400 later. So it
has a duration. I chose Date as Day implies the sun is shining :)

> A Date does not in my mind represent a "specific historic period", but I am no expert
> of course.

If you are interested, the design came from my experience of off-by-one errors when
manipluating the jail sentences (and other such) things in VisualAge for a certain
South Pacific nation.

Hence, a given Date occupies all 86400 seconds it legally spans and can be used
with the other Timespan classes to correctly calculate intersections, etc.

> PS. We also use the Timezone stuff from David Lewis and that also ties
> into this using class PointInTime etc. Phew.

David developed his class in isolation - I only learnt of it when he announced it.

Much of the features he offers are related to time zones. The existing chronology
package does support the basics of time zones with an eye to adding daylight saving
later.

I did not add that as I live in a country with only one time zone and no daylight saving.
There is no reason Dave's functionality could not be included.

Brent

hi guys

What I think that we should do is the following:
You decide, collect, run the tests and once this is done you ping,  
publish the new package to be integrated in
the inbox of the squeakfoundation and I integrated as the first new  
package of 3.10.


Now recently I was thinking that retrospectively it would have been  
better to keep a really small
and limited core class (that the system only requires) and have  
separate and loadable time packages.
I have the impression that aconcagua for example is circuventing some  
limits of Brent packages...
So having packages that are not tied to the kernel would make their  
evolution/tests/maintenance
easier. What do you think about that?

Stef


On 31 août 06, at 14:22, Brent Pinkney wrote:

> I have the impression that aconcagua for example is circuventing some  
> limits of Brent packages...

Perhaps - no one informs me though.

> So having packages that are not tied to the kernel would make their  
> evolution/tests/maintenance easier. What do you think about that?

Nice in theory - hard in practice. The Date and Time classes are heavily used
by the IDE to update the version history and changes files.

So it is hard to simply file-in a replacement package. My original chanset used
all sorts of #become to file in the new classes and then swap over.


Cheers

I remember doing some experiments on this, getting rid of those expensive
quo: calls.
Good work!

On 31 août 06, at 14:42, Brent Pinkney wrote:

>> I have the impression that aconcagua for example is circuventing some
>> limits of Brent packages...

May be you should read the paper of hernan that was published last  
year at ESUG.

Brent
in that scenario clients of a package just use BPDate or HernanDate
but not the core ones. I was just thinking about that so this is not  
serious :).
But this was going with some thoughts of what is a core? where do we  
stop?


Stef


>
>
> Cheers
>

> > PS. We also use the Timezone stuff from David Lewis and that also ties
> > into this using class PointInTime etc. Phew.
>
> David developed his class in isolation - I only learnt of it when he announced it.

FWIW, I posted the timezone stuff back in 1999. Just for laughs, here
is from my original post:

  Date: Wed, 22 Dec 1999 11:18:47 -0500
  From: "David T. Lewis" <[hidden email]>
  To: [hidden email]
  Subject: [ENH][GOODIE] Time Zone Support for Squeak
 
  As the end of the millenium nears, I am moved to attempt the creation of a
  work of enduring value and social import: A Squeak utility for scheduling
  New Years Eve celebrations in synchronization with the coming of the year
  2000 in every known time zone around the world. Particularly ambitious
  revelers may elect to hoist a cup twice for each geographic zone, once for
  each time zone as represented casually on most computers, and once again 22
  seconds later in recognition of the influence of leap seconds on local time
  observances.
 
  Of possible incidental interest to more sober observers of the millenial
  transition, I am including a time zone database which can be initialized
  from data in tzfile formatted time zone files as found on many newer Unix
  systems, especially Linux and FreeBSD. The database answers UTC offsets for
  each time zone at any point in time, and includes leap second compensation
  for time zones whose tzfile data includes a leap second table.
 
  After loading the change set and initializing from the time zone files on
  your computer (or from a small set of representative files which I have
  provided as examples), inspect "TimeZoneDatabase partyTimes" to obtain the
  essential revelry schedule.
 
  Happy New Year!

> Much of the features he offers are related to time zones. The existing chronology
> package does support the basics of time zones with an eye to adding daylight saving
> later.

Exactly so. My time zone stuff does not do any of the calendar related
things in Chronology, and there should be no conflict at all between the
two. After Chronology was incorporated into Squeak, I added some hooks
to assist in time conversion with time zones. I used your time zone
hooks, and it works just fine.

The PointInTime class in TimeZoneDatabase is there for two reasons:

1) I wrote it to support Squeak, ST/X, and VisualWorks, and needed
something that worked across Smalltalk platforms.

2) I needed an abstaction for absolute time independent of the
earth-rotation representation of time (calendars, etc). Without
that, it's pretty hard to get things like leap seconds right.

> I did not add that as I live in a country with only one time zone
> and no daylight saving. There is no reason Dave's functionality
> could not be included.

Agreed, although I would have to say that most people do not need
a good time zone representation for everyday use. It's a rather
large package so it really should to be kept separate from the base
image. It's easily loadable by anybody who does need it, so I think
it's best to keep it as an external package. Probably most Seaside
applications would want to have it available, but the majority
of Squeak users probably would not.

Having said that, I think there is something to be learned from
the PointInTime class. On recent Squeak, it uses ScaledDecimal to
represent time values. This turns out to work really well. You can
represent any precision you want (not just milliseconds, nanoseconds,
or any other specific granularity). And as a practical matter, the
actual time values the are reported by the underlying system are
always integral values, which causes time arithmetic based on
ScaledDecimal to be very efficient.

Dave

Hi!

Brent Pinkney <[hidden email]> wrote:
> Hi,
>
> From the Mantis issue:
> I am nominally responsible for the Chronology package since I wrote it :)

Yup :)
 
Cool! :) Even though the tests passes I might (not sure) have introduced
some subtle problems when creating Durations using non integer
arguments. I think my latest sweep of the code managed to get it right,
but I am just hoisting a small warning flag.

> ---------------------------------------------------------------------------------------------------------------
> > It would be nice if someone could summarize all Time related
> > classes and when to use which one. There is plenty of them these days.
>
> I developed the Chronology class to precisely solve the problem of many Time classes.
> If you read the original wiki page (http://minnow.cc.gatech.edu/squeak/1871) I refer to
> my experience with Java/J++ where there were 6 different class libraries to choose from.

Ok, I read it and it explains quite a bit. We also have TimeStamp in the
3.8 image. It seems to me that TimeStamp (which has a Date and a Time)
is a "duplication" of DateAndTime.

> I added the support for nano second precision precisely to future-proof the design.
>
> > For example, Date as you mention seems IMHO also like it still could be
> > stored as a julian day number. A "Date beast" with duration etc seems
> > like it probably could be called a Day instead.
>
> Perhaps, but a Date definately starts at midnight and ends 86400 later. So it
> has a duration. I chose Date as Day implies the sun is shining :)

Probably. It just seems odd to me (and to Bert) that it needs to contain
all that it contains today. I mean, in *essence* it should be enough
with the julian day number, right? Or what does the duration etc buy us
in this case?

regards, Göran