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 vstinner
Recipients MrJean1, alexandre.vassalotti, belopolsky, gregory.p.smith, kristjan.jonsson, nirai, pitrou, vstinner
Date 2012-09-22.00:54:28
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1348275270.21.0.271320807913.issue2281@psf.upfronthosting.co.za>
In-reply-to
Content
Reading directly the CPU timestamp counter is not a good idea.

> One issue with using timestamp counters is that their resolution varies
> with CPU speed, which is not necessarily constant during a whole run
> (because of power management). On the other hand I'm not sure it's
> really a problem.

There is another major issue: you have to synchronize the counter of all CPU cores. Windows XP didn't synchronize the counters, and it was a major issue on QueryPerformanceCounter.
http://support.microsoft.com/?id=896256

It is really better to rely on the OS rather than querying directly the hardward. The OS (well, most OS except Windows) handles all these minor "nits" and provide the best possible resolution.

--

> Python 3.3 has a new time.perf_counter() function.
> It may be possible to expose this function in C ...

Oh, I now remember why I didn't do this before: when clock_gettime() function is used in perf_counter(), the program or library must be linked to librt on most Linux distro. It was easier to only handle this correctly for the time module. We can do something similar on the _lsprof module.
History
Date User Action Args
2012-09-22 00:54:30vstinnersetrecipients: + vstinner, gregory.p.smith, belopolsky, pitrou, kristjan.jonsson, alexandre.vassalotti, MrJean1, nirai
2012-09-22 00:54:30vstinnersetmessageid: <1348275270.21.0.271320807913.issue2281@psf.upfronthosting.co.za>
2012-09-22 00:54:29vstinnerlinkissue2281 messages
2012-09-22 00:54:28vstinnercreate