[Pharo-project] System time

Andres Valloud avalloud at smalltalk.comcastbiz.net
Mon May 2 13:02:13 CEST 2011

Ok, so each time you add the offset things become more and more imprecise...


"The default precision of the timeGetTime function can be five 
milliseconds or more, depending on the machine. You can use the 
timeBeginPeriod and timeEndPeriod functions to increase the precision of 
timeGetTime. If you do so, the minimum difference between successive 
values returned by timeGetTime can be as large as the minimum period 
value set using timeBeginPeriod and timeEndPeriod."

Note you cannot even assume what the precision is because the function 
timeBeginPeriod() changes the precision for EVERY program (plus it has 
other side effects).  Of course, then the docs state

"Use the QueryPerformanceCounter and QueryPerformanceFrequency functions 
to measure short time intervals at a high resolution"

even though the relevant specs mention all sorts of problems when one 
uses QueryPerformanceCounter().  This is typical MSDN, unfortunately.

On 5/2/11 3:56 , Henrik Sperre Johansen wrote:
> On 02.05.2011 00:56, Andres Valloud wrote:
>> Does the Windows VM depend on QueryPerformanceCounter()?
> The Cog VM (which it seemed Jimmie was using) uses a clock
> (sqWin32Heartbeat.c) initialized with
> GetSystemTimeAsFileTime and timeGetTime
> then adds an offset based on current timeGetTime (reinitialization
> happens at rollovers)
> I can't see any mention of drift in the Microsoft documentation of
> timeGetTime, but I guess there must be some?
> Cheers,
> Henry

More information about the Pharo-project mailing list