Timestamp performance through the years

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

Timestamp performance through the years

Boris Popov, DeepCove Labs (SNN)

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
Reply | Threaded
Open this post in threaded view
|

Re: Timestamp performance through the years

mkobetic
"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
Reply | Threaded
Open this post in threaded view
|

Re: Timestamp performance through the years

Boris Popov, DeepCove Labs (SNN)
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
Reply | Threaded
Open this post in threaded view
|

Re: Timestamp performance through the years

Joerg Beekmann, DeepCove Labs (YVR)
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
Reply | Threaded
Open this post in threaded view
|

Re: Timestamp performance through the years

Andres Valloud-6
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
Reply | Threaded
Open this post in threaded view
|

Re: Timestamp performance through the years

Joerg Beekmann, DeepCove Labs (YVR)
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
Reply | Threaded
Open this post in threaded view
|

Re: Timestamp performance through the years

Andres Valloud-6
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
Reply | Threaded
Open this post in threaded view
|

Re: Timestamp performance through the years

Boris Popov, DeepCove Labs (SNN)
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
Reply | Threaded
Open this post in threaded view
|

Re: Timestamp performance through the years

Andres Valloud-6
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
Reply | Threaded
Open this post in threaded view
|

Re: Timestamp performance through the years

Joerg Beekmann, DeepCove Labs (YVR)
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
Reply | Threaded
Open this post in threaded view
|

Re: Timestamp performance through the years

Michael Lucas-Smith-2
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
Reply | Threaded
Open this post in threaded view
|

Re: Timestamp performance through the years

Joerg Beekmann, DeepCove Labs (YVR)
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
Reply | Threaded
Open this post in threaded view
|

Re: Timestamp performance through the years

Wai Lun Mang
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.

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


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc