This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author brian.curtin
Recipients anacrolix, belopolsky, brian.curtin, eric.araujo, glenn, kristjan.jonsson, michael.foord, pitrou, vstinner
Date 2011-01-14.16:34:35
SpamBayes Score 3.551786e-05
Marked as misclassified No
Message-id <1295022880.89.0.0780117098464.issue10278@psf.upfronthosting.co.za>
In-reply-to
Content
> In Windows, it should probably use GetTickCount64 if available,
> otherwise GetTickCount with logic to handle wrapping.  I think
> QueryPerformanceCounter is problematic as a general-purpose timer:
> depending on the hardware and Windows version, it can be offset
> differently across CPUs, and may not be reliable on some processors.  It
> may be fixed in Vista or Win7, I'm not sure; if so it's much higher
> resolution than GTC.

I don't have a ton of experience with this, but by creating a synchronization point based on when the system clock changes, QueryPerformanceCounter can be pretty accurate and as you already stated, and higher resolution than most other solutions. http://msdn.microsoft.com/en-us/magazine/cc163996.aspx is where I got the idea and most of the implementation from. I'm essentially using the code from Figure 2 in a C extension right now to do something similar to threading.Timer in a performance testing tool.
History
Date User Action Args
2011-01-14 16:34:40brian.curtinsetrecipients: + brian.curtin, belopolsky, pitrou, kristjan.jonsson, vstinner, eric.araujo, michael.foord, glenn, anacrolix
2011-01-14 16:34:40brian.curtinsetmessageid: <1295022880.89.0.0780117098464.issue10278@psf.upfronthosting.co.za>
2011-01-14 16:34:36brian.curtinlinkissue10278 messages
2011-01-14 16:34:35brian.curtincreate