Timestamp performance through the years
Locked
Timestamp performance through the years
 
|
Windows 7 SP1 @ Intel i7 940 2.93GHz, "7.5" Time millisecondsToRun: [1000000 timesRepeat: [Timestamp now]] 3653 3498 3677 "7.6" Time millisecondsToRun: [1000000 timesRepeat: [Timestamp now]] 3623 3713 3790 "7.7" Time millisecondsToRun: [1000000 timesRepeat: [Timestamp now]] 5672 5532 5510 "7.7.1" Time millisecondsToRun: [1000000 timesRepeat: [Timestamp now]] 5883 5902 5869 I guess the question is, any ideas for how we could speed things up a bit on a low level? It’s started showing up in profiles recently, taking as much as 20% of the time on tests that do a lot of time-sensitive calculation. -Boris _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
|
|
"Boris Popov, DeepCove Labs"<[hidden email]> wrote:
> I guess the question is, any ideas for how we could speed things up a > bit on a low level? It's started showing up in profiles recently, taking > as much as 20% of the time on tests that do a lot of time-sensitive > calculation. My first guess would be that the increase in 7.7 is due to the switch to SystemTimeZone. Timestamps are generally local so we need to convert the universal microsecond clock count to local TZ. Don't know how you could speed up STZ itself, presumably it's primarily the cost of the external calls which you can't really avoid, but you can certainly swap in something else (e.g. the classic TZ), which may or may not work fine for you. Alternatively you could give Chronos a try as it's an all encompassing all-in-smalltalk solution, presumably trading some speed for some memory. But I don't really know how Chronos fares performance-wise. HTH, Martin _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: Timestamp performance through the years
|
|
I'm pondering using an approximation (Timestamp nowish) that caches a
response for period of time avoiding expensive conversion for, say, 100ms or whatever suits. I'll report back. -Boris -----Original Message----- From: [hidden email] [mailto:[hidden email]] Sent: 26 April 2011 15:54 To: Boris Popov, DeepCove Labs Cc: [hidden email] Subject: Re: [vwnc] Timestamp performance through the years "Boris Popov, DeepCove Labs"<[hidden email]> wrote: > I guess the question is, any ideas for how we could speed things up a > bit on a low level? It's started showing up in profiles recently, > taking as much as 20% of the time on tests that do a lot of > time-sensitive calculation. My first guess would be that the increase in 7.7 is due to the switch to SystemTimeZone. Timestamps are generally local so we need to convert the universal microsecond clock count to local TZ. Don't know how you could speed up STZ itself, presumably it's primarily the cost of the external calls which you can't really avoid, but you can certainly swap in something else (e.g. the classic TZ), which may or may not work fine for you. Alternatively you could give Chronos a try as it's an all encompassing all-in-smalltalk solution, presumably trading some speed for some memory. But I don't really know how Chronos fares performance-wise. HTH, Martin _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: Timestamp performance through the years
|
|
In reply to this post by mkobetic
Since Boris suggested nowish as something that would return an
approximate time I thought I would give that a try: Time millisecondsToRun: [1000000 timesRepeat: [Timestamp nowish]] 694 670 705 nowish "Answer a Timestamp close to the current local time." "Timestamp nowish" | milliseconds | milliseconds := Time millisecondClockValue. (cachedMS isNil or: [(milliseconds - cachedMS) abs > 5000]) ifTrue: [cachedMS := milliseconds. nowish := self now]. ^nowish -----Original Message----- From: [hidden email] [mailto:[hidden email]] On Behalf Of [hidden email] Sent: Tuesday, April 26, 2011 12:54 PM To: Boris Popov, DeepCove Labs Cc: [hidden email] Subject: Re: [vwnc] Timestamp performance through the years "Boris Popov, DeepCove Labs"<[hidden email]> wrote: > I guess the question is, any ideas for how we could speed things up a > bit on a low level? It's started showing up in profiles recently, taking > as much as 20% of the time on tests that do a lot of time-sensitive > calculation. My first guess would be that the increase in 7.7 is due to the switch to SystemTimeZone. Timestamps are generally local so we need to convert the universal microsecond clock count to local TZ. Don't know how you could speed up STZ itself, presumably it's primarily the cost of the external calls which you can't really avoid, but you can certainly swap in something else (e.g. the classic TZ), which may or may not work fine for you. Alternatively you could give Chronos a try as it's an all encompassing all-in-smalltalk solution, presumably trading some speed for some memory. But I don't really know how Chronos fares performance-wise. HTH, Martin _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: Timestamp performance through the years
|
|
If you use the microsecondClock directly, nowish runs even faster...
On 4/26/2011 1:02 PM, Joerg Beekmann, DeepCove Labs wrote: > Since Boris suggested nowish as something that would return an > approximate time I thought I would give that a try: > > Time millisecondsToRun: [1000000 timesRepeat: [Timestamp nowish]] 694 > 670 705 > > nowish > "Answer a Timestamp close to the current local time." > "Timestamp nowish" > > | milliseconds | > milliseconds := Time millisecondClockValue. > (cachedMS isNil or: [(milliseconds - cachedMS) abs> 5000]) > ifTrue: > [cachedMS := milliseconds. > nowish := self now]. > ^nowish > > -----Original Message----- > From: [hidden email] [mailto:[hidden email]] On > Behalf Of [hidden email] > Sent: Tuesday, April 26, 2011 12:54 PM > To: Boris Popov, DeepCove Labs > Cc: [hidden email] > Subject: Re: [vwnc] Timestamp performance through the years > > "Boris Popov, DeepCove Labs"<[hidden email]> wrote: >> I guess the question is, any ideas for how we could speed things up a >> bit on a low level? It's started showing up in profiles recently, > taking >> as much as 20% of the time on tests that do a lot of time-sensitive >> calculation. > > My first guess would be that the increase in 7.7 is due to the switch to > SystemTimeZone. Timestamps are generally local so we need to convert the > universal microsecond clock count to local TZ. Don't know how you could > speed up STZ itself, presumably it's primarily the cost of the external > calls which you can't really avoid, but you can certainly swap in > something else (e.g. the classic TZ), which may or may not work fine for > you. Alternatively you could give Chronos a try as it's an all > encompassing all-in-smalltalk solution, presumably trading some speed > for some memory. But I don't really know how Chronos fares > performance-wise. > > HTH, > > Martin > > _______________________________________________ > vwnc mailing list > [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > > _______________________________________________ > vwnc mailing list > [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: Timestamp performance through the years
|
|
True; doing that and replacing the or: with "isNil ifTrue: []" takes it
down to about 520ms -----Original Message----- From: [hidden email] [mailto:[hidden email]] On Behalf Of Andres Valloud Sent: Tuesday, April 26, 2011 1:18 PM To: [hidden email] Subject: Re: [vwnc] Timestamp performance through the years If you use the microsecondClock directly, nowish runs even faster... On 4/26/2011 1:02 PM, Joerg Beekmann, DeepCove Labs wrote: > Since Boris suggested nowish as something that would return an > approximate time I thought I would give that a try: > > Time millisecondsToRun: [1000000 timesRepeat: [Timestamp nowish]] 694 > 670 705 > > nowish > "Answer a Timestamp close to the current local time." > "Timestamp nowish" > > | milliseconds | > milliseconds := Time millisecondClockValue. > (cachedMS isNil or: [(milliseconds - cachedMS) abs> 5000]) > ifTrue: > [cachedMS := milliseconds. > nowish := self now]. > ^nowish > > -----Original Message----- > From: [hidden email] [mailto:[hidden email]] On > Behalf Of [hidden email] > Sent: Tuesday, April 26, 2011 12:54 PM > To: Boris Popov, DeepCove Labs > Cc: [hidden email] > Subject: Re: [vwnc] Timestamp performance through the years > > "Boris Popov, DeepCove Labs"<[hidden email]> wrote: >> I guess the question is, any ideas for how we could speed things up a >> bit on a low level? It's started showing up in profiles recently, > taking >> as much as 20% of the time on tests that do a lot of time-sensitive >> calculation. > > My first guess would be that the increase in 7.7 is due to the switch > SystemTimeZone. Timestamps are generally local so we need to convert the > universal microsecond clock count to local TZ. Don't know how you could > speed up STZ itself, presumably it's primarily the cost of the external > calls which you can't really avoid, but you can certainly swap in > something else (e.g. the classic TZ), which may or may not work fine for > you. Alternatively you could give Chronos a try as it's an all > encompassing all-in-smalltalk solution, presumably trading some speed > for some memory. But I don't really know how Chronos fares > performance-wise. > > HTH, > > Martin > > _______________________________________________ > vwnc mailing list > [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > > _______________________________________________ > vwnc mailing list > [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: Timestamp performance through the years
|
|
So, just out of curiosity, what timestamp precision do you need? Is a
timestamp correct to within 1 millisecond enough? On 4/26/2011 1:41 PM, Joerg Beekmann, DeepCove Labs wrote: > True; doing that and replacing the or: with "isNil ifTrue: []" takes it > down to about 520ms > > -----Original Message----- > From: [hidden email] [mailto:[hidden email]] On > Behalf Of Andres Valloud > Sent: Tuesday, April 26, 2011 1:18 PM > To: [hidden email] > Subject: Re: [vwnc] Timestamp performance through the years > > If you use the microsecondClock directly, nowish runs even faster... > > On 4/26/2011 1:02 PM, Joerg Beekmann, DeepCove Labs wrote: >> Since Boris suggested nowish as something that would return an >> approximate time I thought I would give that a try: >> >> Time millisecondsToRun: [1000000 timesRepeat: [Timestamp nowish]] 694 >> 670 705 >> >> nowish >> "Answer a Timestamp close to the current local time." >> "Timestamp nowish" >> >> | milliseconds | >> milliseconds := Time millisecondClockValue. >> (cachedMS isNil or: [(milliseconds - cachedMS) abs> 5000]) >> ifTrue: >> [cachedMS := milliseconds. >> nowish := self now]. >> ^nowish >> >> -----Original Message----- >> From: [hidden email] [mailto:[hidden email]] On >> Behalf Of [hidden email] >> Sent: Tuesday, April 26, 2011 12:54 PM >> To: Boris Popov, DeepCove Labs >> Cc: [hidden email] >> Subject: Re: [vwnc] Timestamp performance through the years >> >> "Boris Popov, DeepCove Labs"<[hidden email]> wrote: >>> I guess the question is, any ideas for how we could speed things up a >>> bit on a low level? It's started showing up in profiles recently, >> taking >>> as much as 20% of the time on tests that do a lot of time-sensitive >>> calculation. >> >> My first guess would be that the increase in 7.7 is due to the switch > to >> SystemTimeZone. Timestamps are generally local so we need to convert > the >> universal microsecond clock count to local TZ. Don't know how you > could >> speed up STZ itself, presumably it's primarily the cost of the > external >> calls which you can't really avoid, but you can certainly swap in >> something else (e.g. the classic TZ), which may or may not work fine > for >> you. Alternatively you could give Chronos a try as it's an all >> encompassing all-in-smalltalk solution, presumably trading some speed >> for some memory. But I don't really know how Chronos fares >> performance-wise. >> >> HTH, >> >> Martin >> >> _______________________________________________ >> vwnc mailing list >> [hidden email] >> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc >> >> _______________________________________________ >> vwnc mailing list >> [hidden email] >> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc >> > _______________________________________________ > vwnc mailing list > [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: Timestamp performance through the years
|
|
Even less as SQL server only stores 33 within a second or so if I recall :)
Sent from my iPhone On 2011-04-26, at 16:56, "Andres Valloud" <[hidden email]> wrote: > So, just out of curiosity, what timestamp precision do you need? Is a > timestamp correct to within 1 millisecond enough? > > On 4/26/2011 1:41 PM, Joerg Beekmann, DeepCove Labs wrote: >> True; doing that and replacing the or: with "isNil ifTrue: []" takes it >> down to about 520ms >> >> -----Original Message----- >> From: [hidden email] [mailto:[hidden email]] On >> Behalf Of Andres Valloud >> Sent: Tuesday, April 26, 2011 1:18 PM >> To: [hidden email] >> Subject: Re: [vwnc] Timestamp performance through the years >> >> If you use the microsecondClock directly, nowish runs even faster... >> >> On 4/26/2011 1:02 PM, Joerg Beekmann, DeepCove Labs wrote: >>> Since Boris suggested nowish as something that would return an >>> approximate time I thought I would give that a try: >>> >>> Time millisecondsToRun: [1000000 timesRepeat: [Timestamp nowish]] 694 >>> 670 705 >>> >>> nowish >>> "Answer a Timestamp close to the current local time." >>> "Timestamp nowish" >>> >>> | milliseconds | >>> milliseconds := Time millisecondClockValue. >>> (cachedMS isNil or: [(milliseconds - cachedMS) abs> 5000]) >>> ifTrue: >>> [cachedMS := milliseconds. >>> nowish := self now]. >>> ^nowish >>> >>> -----Original Message----- >>> From: [hidden email] [mailto:[hidden email]] On >>> Behalf Of [hidden email] >>> Sent: Tuesday, April 26, 2011 12:54 PM >>> To: Boris Popov, DeepCove Labs >>> Cc: [hidden email] >>> Subject: Re: [vwnc] Timestamp performance through the years >>> >>> "Boris Popov, DeepCove Labs"<[hidden email]> wrote: >>>> I guess the question is, any ideas for how we could speed things up a >>>> bit on a low level? It's started showing up in profiles recently, >>> taking >>>> as much as 20% of the time on tests that do a lot of time-sensitive >>>> calculation. >>> >>> My first guess would be that the increase in 7.7 is due to the switch >> to >>> SystemTimeZone. Timestamps are generally local so we need to convert >> the >>> universal microsecond clock count to local TZ. Don't know how you >> could >>> speed up STZ itself, presumably it's primarily the cost of the >> external >>> calls which you can't really avoid, but you can certainly swap in >>> something else (e.g. the classic TZ), which may or may not work fine >> for >>> you. Alternatively you could give Chronos a try as it's an all >>> encompassing all-in-smalltalk solution, presumably trading some speed >>> for some memory. But I don't really know how Chronos fares >>> performance-wise. >>> >>> HTH, >>> >>> Martin >>> >>> _______________________________________________ >>> vwnc mailing list >>> [hidden email] >>> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc >>> >>> _______________________________________________ >>> vwnc mailing list >>> [hidden email] >>> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc >>> >> _______________________________________________ >> vwnc mailing list >> [hidden email] >> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc >> > _______________________________________________ > vwnc mailing list > [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: Timestamp performance through the years
|
|
Oh, so really you only need a new timestamp every 30 milliseconds or
so... time to increase the nowish threshold :). I wonder how fast will it go! On 4/26/2011 2:03 PM, Boris Popov, DeepCove Labs wrote: > Even less as SQL server only stores 33 within a second or so if I recall :) > > Sent from my iPhone > > On 2011-04-26, at 16:56, "Andres Valloud"<[hidden email]> wrote: > >> So, just out of curiosity, what timestamp precision do you need? Is a >> timestamp correct to within 1 millisecond enough? >> >> On 4/26/2011 1:41 PM, Joerg Beekmann, DeepCove Labs wrote: >>> True; doing that and replacing the or: with "isNil ifTrue: []" takes it >>> down to about 520ms >>> >>> -----Original Message----- >>> From: [hidden email] [mailto:[hidden email]] On >>> Behalf Of Andres Valloud >>> Sent: Tuesday, April 26, 2011 1:18 PM >>> To: [hidden email] >>> Subject: Re: [vwnc] Timestamp performance through the years >>> >>> If you use the microsecondClock directly, nowish runs even faster... >>> >>> On 4/26/2011 1:02 PM, Joerg Beekmann, DeepCove Labs wrote: >>>> Since Boris suggested nowish as something that would return an >>>> approximate time I thought I would give that a try: >>>> >>>> Time millisecondsToRun: [1000000 timesRepeat: [Timestamp nowish]] 694 >>>> 670 705 >>>> >>>> nowish >>>> "Answer a Timestamp close to the current local time." >>>> "Timestamp nowish" >>>> >>>> | milliseconds | >>>> milliseconds := Time millisecondClockValue. >>>> (cachedMS isNil or: [(milliseconds - cachedMS) abs> 5000]) >>>> ifTrue: >>>> [cachedMS := milliseconds. >>>> nowish := self now]. >>>> ^nowish >>>> >>>> -----Original Message----- >>>> From: [hidden email] [mailto:[hidden email]] On >>>> Behalf Of [hidden email] >>>> Sent: Tuesday, April 26, 2011 12:54 PM >>>> To: Boris Popov, DeepCove Labs >>>> Cc: [hidden email] >>>> Subject: Re: [vwnc] Timestamp performance through the years >>>> >>>> "Boris Popov, DeepCove Labs"<[hidden email]> wrote: >>>>> I guess the question is, any ideas for how we could speed things up a >>>>> bit on a low level? It's started showing up in profiles recently, >>>> taking >>>>> as much as 20% of the time on tests that do a lot of time-sensitive >>>>> calculation. >>>> >>>> My first guess would be that the increase in 7.7 is due to the switch >>> to >>>> SystemTimeZone. Timestamps are generally local so we need to convert >>> the >>>> universal microsecond clock count to local TZ. Don't know how you >>> could >>>> speed up STZ itself, presumably it's primarily the cost of the >>> external >>>> calls which you can't really avoid, but you can certainly swap in >>>> something else (e.g. the classic TZ), which may or may not work fine >>> for >>>> you. Alternatively you could give Chronos a try as it's an all >>>> encompassing all-in-smalltalk solution, presumably trading some speed >>>> for some memory. But I don't really know how Chronos fares >>>> performance-wise. >>>> >>>> HTH, >>>> >>>> Martin >>>> >>>> _______________________________________________ >>>> vwnc mailing list >>>> [hidden email] >>>> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc >>>> >>>> _______________________________________________ >>>> vwnc mailing list >>>> [hidden email] >>>> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc >>>> >>> _______________________________________________ >>> vwnc mailing list >>> [hidden email] >>> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc >>> >> _______________________________________________ >> vwnc mailing list >> [hidden email] >> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: Timestamp performance through the years
|
|
I guess rather than a fixed definition of "nowish" the thing to do is have nowWithIn: milliseconds. For cases where you quickly want a timestamp set to the correct time zone but don't need a great deal of accuracy. Now amazingly enough it seems you can get timestamp accurate to the millisecond about 10 times faster than the naïve approach. In fact I'm not sure I believe it so here is the code.
nowWithin: tolerance "Answer a Timestamp close to the current local time." "cachedMS and nowish are class inst vars of Timestamp" "Timestamp nowish" | microseconds | microseconds := Time microsecondClock. cachedMS isNil ifTrue: [cachedMS := Time microsecondClock - (tolerance * 2)]. ((microseconds - cachedMS) abs > (tolerance)) ifTrue: [cachedMS := microseconds. nowish := self now]. ^nowish Time millisecondsToRun: [1000000 timesRepeat: [Timestamp nowWithin: 300]] 550 622 584 vs Time millisecondsToRun: [1000000 timesRepeat: [Timestamp now ]] 8062 8191 8243 In fact since the Timestamp class is only accurate to milliseconds nowWithin: for tolerances of under 300 microseconds can be considered just as valid as now. Increasing the tolerance provides little benefit. Joerg -----Original Message----- From: [hidden email] [mailto:[hidden email]] On Behalf Of Andres Valloud Sent: Tuesday, April 26, 2011 2:14 PM To: [hidden email] Subject: Re: [vwnc] Timestamp performance through the years Oh, so really you only need a new timestamp every 30 milliseconds or so... time to increase the nowish threshold :). I wonder how fast will it go! On 4/26/2011 2:03 PM, Boris Popov, DeepCove Labs wrote: > Even less as SQL server only stores 33 within a second or so if I recall :) > > Sent from my iPhone > > On 2011-04-26, at 16:56, "Andres Valloud"<[hidden email]> wrote: > >> So, just out of curiosity, what timestamp precision do you need? Is a >> timestamp correct to within 1 millisecond enough? >> >> On 4/26/2011 1:41 PM, Joerg Beekmann, DeepCove Labs wrote: >>> True; doing that and replacing the or: with "isNil ifTrue: []" takes it >>> down to about 520ms >>> >>> -----Original Message----- >>> From: [hidden email] [mailto:[hidden email]] On >>> Behalf Of Andres Valloud >>> Sent: Tuesday, April 26, 2011 1:18 PM >>> To: [hidden email] >>> Subject: Re: [vwnc] Timestamp performance through the years >>> >>> If you use the microsecondClock directly, nowish runs even faster... >>> >>> On 4/26/2011 1:02 PM, Joerg Beekmann, DeepCove Labs wrote: >>>> Since Boris suggested nowish as something that would return an >>>> approximate time I thought I would give that a try: >>>> >>>> Time millisecondsToRun: [1000000 timesRepeat: [Timestamp nowish]] 694 >>>> 670 705 >>>> >>>> nowish >>>> "Answer a Timestamp close to the current local time." >>>> "Timestamp nowish" >>>> >>>> | milliseconds | >>>> milliseconds := Time millisecondClockValue. >>>> (cachedMS isNil or: [(milliseconds - cachedMS) abs> 5000]) >>>> ifTrue: >>>> [cachedMS := milliseconds. >>>> nowish := self now]. >>>> ^nowish >>>> >>>> -----Original Message----- >>>> From: [hidden email] [mailto:[hidden email]] On >>>> Behalf Of [hidden email] >>>> Sent: Tuesday, April 26, 2011 12:54 PM >>>> To: Boris Popov, DeepCove Labs >>>> Cc: [hidden email] >>>> Subject: Re: [vwnc] Timestamp performance through the years >>>> >>>> "Boris Popov, DeepCove Labs"<[hidden email]> wrote: >>>>> I guess the question is, any ideas for how we could speed things up a >>>>> bit on a low level? It's started showing up in profiles recently, >>>> taking >>>>> as much as 20% of the time on tests that do a lot of time-sensitive >>>>> calculation. >>>> >>>> My first guess would be that the increase in 7.7 is due to the switch >>> to >>>> SystemTimeZone. Timestamps are generally local so we need to convert >>> the >>>> universal microsecond clock count to local TZ. Don't know how you >>> could >>>> speed up STZ itself, presumably it's primarily the cost of the >>> external >>>> calls which you can't really avoid, but you can certainly swap in >>>> something else (e.g. the classic TZ), which may or may not work fine >>> for >>>> you. Alternatively you could give Chronos a try as it's an all >>>> encompassing all-in-smalltalk solution, presumably trading some speed >>>> for some memory. But I don't really know how Chronos fares >>>> performance-wise. >>>> >>>> HTH, >>>> >>>> Martin >>>> >>>> _______________________________________________ >>>> vwnc mailing list >>>> [hidden email] >>>> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc >>>> >>>> _______________________________________________ >>>> vwnc mailing list >>>> [hidden email] >>>> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc >>>> >>> _______________________________________________ >>> vwnc mailing list >>> [hidden email] >>> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc >>> >> _______________________________________________ >> vwnc mailing list >> [hidden email] >> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: Timestamp performance through the years
|
|
I thought I'd chime in because I have some work with Timestamps currently in progress. We're adding an offset variable to Timestamp, so the need to compute seconds via the OS apis will completely disappear. You should see the full speed you used to have again once that is done. The only external calls will be during Timestamp instantiation -if- you don't want a UTC timestamp and you are using SystemTimeZone (which will remain the default as it is the most common thing). Timestamp nowUTC will be as fast as it can get, Timestamp now should be almost as fast as it used to be.
Please let me know if you have any concerns regarding the addition of an offset variable to Timestamp. Cheers, Michael On Apr 26, 2011, at 3:48 PM, Joerg Beekmann, DeepCove Labs wrote: > I guess rather than a fixed definition of "nowish" the thing to do is have nowWithIn: milliseconds. For cases where you quickly want a timestamp set to the correct time zone but don't need a great deal of accuracy. Now amazingly enough it seems you can get timestamp accurate to the millisecond about 10 times faster than the naïve approach. In fact I'm not sure I believe it so here is the code. > > nowWithin: tolerance > "Answer a Timestamp close to the current local time." > "cachedMS and nowish are class inst vars of Timestamp" > "Timestamp nowish" > > | microseconds | > microseconds := Time microsecondClock. > cachedMS isNil ifTrue: [cachedMS := Time microsecondClock - (tolerance * 2)]. > ((microseconds - cachedMS) abs > (tolerance)) > ifTrue: > [cachedMS := microseconds. > nowish := self now]. > ^nowish > > > Time millisecondsToRun: [1000000 timesRepeat: [Timestamp nowWithin: 300]] 550 622 584 > vs > Time millisecondsToRun: [1000000 timesRepeat: [Timestamp now ]] 8062 8191 8243 > > > In fact since the Timestamp class is only accurate to milliseconds nowWithin: for tolerances of under 300 microseconds can be considered just as valid as now. Increasing the tolerance provides little benefit. > > Joerg > > > > -----Original Message----- > From: [hidden email] [mailto:[hidden email]] On Behalf Of Andres Valloud > Sent: Tuesday, April 26, 2011 2:14 PM > To: [hidden email] > Subject: Re: [vwnc] Timestamp performance through the years > > Oh, so really you only need a new timestamp every 30 milliseconds or > so... time to increase the nowish threshold :). I wonder how fast will > it go! > > On 4/26/2011 2:03 PM, Boris Popov, DeepCove Labs wrote: >> Even less as SQL server only stores 33 within a second or so if I recall :) >> >> Sent from my iPhone >> >> On 2011-04-26, at 16:56, "Andres Valloud"<[hidden email]> wrote: >> >>> So, just out of curiosity, what timestamp precision do you need? Is a >>> timestamp correct to within 1 millisecond enough? >>> >>> On 4/26/2011 1:41 PM, Joerg Beekmann, DeepCove Labs wrote: >>>> True; doing that and replacing the or: with "isNil ifTrue: []" takes it >>>> down to about 520ms >>>> >>>> -----Original Message----- >>>> From: [hidden email] [mailto:[hidden email]] On >>>> Behalf Of Andres Valloud >>>> Sent: Tuesday, April 26, 2011 1:18 PM >>>> To: [hidden email] >>>> Subject: Re: [vwnc] Timestamp performance through the years >>>> >>>> If you use the microsecondClock directly, nowish runs even faster... >>>> >>>> On 4/26/2011 1:02 PM, Joerg Beekmann, DeepCove Labs wrote: >>>>> Since Boris suggested nowish as something that would return an >>>>> approximate time I thought I would give that a try: >>>>> >>>>> Time millisecondsToRun: [1000000 timesRepeat: [Timestamp nowish]] 694 >>>>> 670 705 >>>>> >>>>> nowish >>>>> "Answer a Timestamp close to the current local time." >>>>> "Timestamp nowish" >>>>> >>>>> | milliseconds | >>>>> milliseconds := Time millisecondClockValue. >>>>> (cachedMS isNil or: [(milliseconds - cachedMS) abs> 5000]) >>>>> ifTrue: >>>>> [cachedMS := milliseconds. >>>>> nowish := self now]. >>>>> ^nowish >>>>> >>>>> -----Original Message----- >>>>> From: [hidden email] [mailto:[hidden email]] On >>>>> Behalf Of [hidden email] >>>>> Sent: Tuesday, April 26, 2011 12:54 PM >>>>> To: Boris Popov, DeepCove Labs >>>>> Cc: [hidden email] >>>>> Subject: Re: [vwnc] Timestamp performance through the years >>>>> >>>>> "Boris Popov, DeepCove Labs"<[hidden email]> wrote: >>>>>> I guess the question is, any ideas for how we could speed things up a >>>>>> bit on a low level? It's started showing up in profiles recently, >>>>> taking >>>>>> as much as 20% of the time on tests that do a lot of time-sensitive >>>>>> calculation. >>>>> >>>>> My first guess would be that the increase in 7.7 is due to the switch >>>> to >>>>> SystemTimeZone. Timestamps are generally local so we need to convert >>>> the >>>>> universal microsecond clock count to local TZ. Don't know how you >>>> could >>>>> speed up STZ itself, presumably it's primarily the cost of the >>>> external >>>>> calls which you can't really avoid, but you can certainly swap in >>>>> something else (e.g. the classic TZ), which may or may not work fine >>>> for >>>>> you. Alternatively you could give Chronos a try as it's an all >>>>> encompassing all-in-smalltalk solution, presumably trading some speed >>>>> for some memory. But I don't really know how Chronos fares >>>>> performance-wise. >>>>> >>>>> HTH, >>>>> >>>>> Martin >>>>> >>>>> _______________________________________________ >>>>> vwnc mailing list >>>>> [hidden email] >>>>> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc >>>>> >>>>> _______________________________________________ >>>>> vwnc mailing list >>>>> [hidden email] >>>>> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc >>>>> >>>> _______________________________________________ >>>> vwnc mailing list >>>> [hidden email] >>>> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc >>>> >>> _______________________________________________ >>> vwnc mailing list >>> [hidden email] >>> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc >> > _______________________________________________ > vwnc mailing list > [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > > _______________________________________________ > vwnc mailing list > [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: Timestamp performance through the years
|
|
I can't think of a downside to having an offset variable. But that will probably not address our specific issue.
On my machine vw7.5 computes 1 millon timestamps in about 3 seconds. But caching the timestamp and calculating a new one if the cached one is stale runs 6 times faster. Whether the caching is worth doing depends on how many cache hits which in turn depends on the access rate and the acceptable tolerance. We have quite a large tolerance. I forgot about that dependence when suggesting a cache as general solution, not many folks access timestamps as frequently as doing 1 million in a loop and hence few would see a benefit to a cache with a tolerance as low as 300 microseconds. Joerg -----Original Message----- From: [hidden email] [mailto:[hidden email]] On Behalf Of Michael Lucas-Smith Sent: Tuesday, April 26, 2011 3:56 PM To: VW NC Subject: Re: [vwnc] Timestamp performance through the years I thought I'd chime in because I have some work with Timestamps currently in progress. We're adding an offset variable to Timestamp, so the need to compute seconds via the OS apis will completely disappear. You should see the full speed you used to have again once that is done. The only external calls will be during Timestamp instantiation -if- you don't want a UTC timestamp and you are using SystemTimeZone (which will remain the default as it is the most common thing). Timestamp nowUTC will be as fast as it can get, Timestamp now should be almost as fast as it used to be. Please let me know if you have any concerns regarding the addition of an offset variable to Timestamp. Cheers, Michael On Apr 26, 2011, at 3:48 PM, Joerg Beekmann, DeepCove Labs wrote: > I guess rather than a fixed definition of "nowish" the thing to do is have nowWithIn: milliseconds. For cases where you quickly want a timestamp set to the correct time zone but don't need a great deal of accuracy. Now amazingly enough it seems you can get timestamp accurate to the millisecond about 10 times faster than the naïve approach. In fact I'm not sure I believe it so here is the code. > > nowWithin: tolerance > "Answer a Timestamp close to the current local time." > "cachedMS and nowish are class inst vars of Timestamp" > "Timestamp nowish" > > | microseconds | > microseconds := Time microsecondClock. > cachedMS isNil ifTrue: [cachedMS := Time microsecondClock - (tolerance * 2)]. > ((microseconds - cachedMS) abs > (tolerance)) > ifTrue: > [cachedMS := microseconds. > nowish := self now]. > ^nowish > > > Time millisecondsToRun: [1000000 timesRepeat: [Timestamp nowWithin: 300]] 550 622 584 > vs > Time millisecondsToRun: [1000000 timesRepeat: [Timestamp now ]] 8062 8191 8243 > > > In fact since the Timestamp class is only accurate to milliseconds nowWithin: for tolerances of under 300 microseconds can be considered just as valid as now. Increasing the tolerance provides little benefit. > > Joerg > > > > -----Original Message----- > From: [hidden email] [mailto:[hidden email]] On Behalf Of Andres Valloud > Sent: Tuesday, April 26, 2011 2:14 PM > To: [hidden email] > Subject: Re: [vwnc] Timestamp performance through the years > > Oh, so really you only need a new timestamp every 30 milliseconds or > so... time to increase the nowish threshold :). I wonder how fast will > it go! > > On 4/26/2011 2:03 PM, Boris Popov, DeepCove Labs wrote: >> Even less as SQL server only stores 33 within a second or so if I recall :) >> >> Sent from my iPhone >> >> On 2011-04-26, at 16:56, "Andres Valloud"<[hidden email]> wrote: >> >>> So, just out of curiosity, what timestamp precision do you need? Is a >>> timestamp correct to within 1 millisecond enough? >>> >>> On 4/26/2011 1:41 PM, Joerg Beekmann, DeepCove Labs wrote: >>>> True; doing that and replacing the or: with "isNil ifTrue: []" takes it >>>> down to about 520ms >>>> >>>> -----Original Message----- >>>> From: [hidden email] [mailto:[hidden email]] On >>>> Behalf Of Andres Valloud >>>> Sent: Tuesday, April 26, 2011 1:18 PM >>>> To: [hidden email] >>>> Subject: Re: [vwnc] Timestamp performance through the years >>>> >>>> If you use the microsecondClock directly, nowish runs even faster... >>>> >>>> On 4/26/2011 1:02 PM, Joerg Beekmann, DeepCove Labs wrote: >>>>> Since Boris suggested nowish as something that would return an >>>>> approximate time I thought I would give that a try: >>>>> >>>>> Time millisecondsToRun: [1000000 timesRepeat: [Timestamp nowish]] 694 >>>>> 670 705 >>>>> >>>>> nowish >>>>> "Answer a Timestamp close to the current local time." >>>>> "Timestamp nowish" >>>>> >>>>> | milliseconds | >>>>> milliseconds := Time millisecondClockValue. >>>>> (cachedMS isNil or: [(milliseconds - cachedMS) abs> 5000]) >>>>> ifTrue: >>>>> [cachedMS := milliseconds. >>>>> nowish := self now]. >>>>> ^nowish >>>>> >>>>> -----Original Message----- >>>>> From: [hidden email] [mailto:[hidden email]] On >>>>> Behalf Of [hidden email] >>>>> Sent: Tuesday, April 26, 2011 12:54 PM >>>>> To: Boris Popov, DeepCove Labs >>>>> Cc: [hidden email] >>>>> Subject: Re: [vwnc] Timestamp performance through the years >>>>> >>>>> "Boris Popov, DeepCove Labs"<[hidden email]> wrote: >>>>>> I guess the question is, any ideas for how we could speed things up a >>>>>> bit on a low level? It's started showing up in profiles recently, >>>>> taking >>>>>> as much as 20% of the time on tests that do a lot of time-sensitive >>>>>> calculation. >>>>> >>>>> My first guess would be that the increase in 7.7 is due to the switch >>>> to >>>>> SystemTimeZone. Timestamps are generally local so we need to convert >>>> the >>>>> universal microsecond clock count to local TZ. Don't know how you >>>> could >>>>> speed up STZ itself, presumably it's primarily the cost of the >>>> external >>>>> calls which you can't really avoid, but you can certainly swap in >>>>> something else (e.g. the classic TZ), which may or may not work fine >>>> for >>>>> you. Alternatively you could give Chronos a try as it's an all >>>>> encompassing all-in-smalltalk solution, presumably trading some speed >>>>> for some memory. But I don't really know how Chronos fares >>>>> performance-wise. >>>>> >>>>> HTH, >>>>> >>>>> Martin >>>>> >>>>> _______________________________________________ >>>>> vwnc mailing list >>>>> [hidden email] >>>>> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc >>>>> >>>>> _______________________________________________ >>>>> vwnc mailing list >>>>> [hidden email] >>>>> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc >>>>> >>>> _______________________________________________ >>>> vwnc mailing list >>>> [hidden email] >>>> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc >>>> >>> _______________________________________________ >>> vwnc mailing list >>> [hidden email] >>> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc >> > _______________________________________________ > vwnc mailing list > [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > > _______________________________________________ > vwnc mailing list > [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: Timestamp performance through the years
|
|
Hi Joerg, nice to see you here.
I thought I will chime it, too. I think if you really what to be super fast then the only way I can think of is create a new class which has 2 instance variables (timezone and microsecondClock)
Time millisecondsToRun: [1000000 timesRepeat: [NewClass newWithTimezone: TimeZone default microsecondClock: Time microsecondClock]].
Based on my machine, it is about 200 times faster than
Time millisecondsToRun: [1000000 timesRepeat: [Timestamp now]]
Of course, it might not be very convenient. It really depends on what your use case is. Whenever you want to display or manipulate it you might want to convert it to a Timestamp unless you implement all the api you want to use in the new class.
Mang
On Wed, Apr 27, 2011 at 7:16 AM, Joerg Beekmann, DeepCove Labs <[hidden email]> wrote: I can't think of a downside to having an offset variable. But that will probably not address our specific issue. _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
«
Return to VisualWorks
|
1 view|%1 views
| Free forum by Nabble | Edit this page |