[Python-Dev] Use QueryPerformanceCounter() for time.monotonic() and/or time.highres()? (original) (raw)

Victor Stinner victor.stinner at gmail.com
Sat Mar 31 04:12:34 CEST 2012

Impact: A timeout may be 42 seconds shorter than the requested duration if is uses QPC. For a scheduler, a task would be scheduled at the right moment. I don't understand this paragraph. And why is it always exactly a loss of 42 seconds?

Sorry, it's late here, I'm too tired. A jump of 42 seconds is one of QPC known bug (it was a bug in VirtualBox and it is now fixed).

So is it worth having two functions that are only different on Windows? ISTM that the average non-Windows user will have a 50% chance of picking the wrong timer from a portability perspective.

Can we solve this by documenting correctly time.highres() issues (it's not really monotonic) and when you need to use time.monotonic() or time.highres()?

Well, there is already time.clock() that uses QPC on Windows, but time.highres() and time.clock() give different results for an idle process on UNIX. pybench, timeit and other programs have their own heuristic getting the most accurate clock depending on the OS and on which clocks are available. time.highres() is a portable function for these programs.

See Zooko Wilcox-O'Hearn's email: http://mail.python.org/pipermail/python-dev/2012-March/118147.html He explains the basic difference between the two types of clocks, and that's important. He doesn't say anything about a strict requirement for monotonicity or steadiness. This is why I still balk at "monotonic" for the name -- I don't think that monotonicity is the most important property. But I don't know how the put the desired requirement in words; "steady" seems to come closer for sure.

If we provide a way to check if the monotonic clock is monotonic (or not), I agree to drop the flag from time.monotonic(fallback=True) and always fallback. I was never a fan of the "truly monotonic clock".

time.clock_info('monotonic')['is_monotonic'] is a good candidate to store this information.

"time.clock_info('monotonic')['is_monotonic']" looks like a bug: why would I check if a monotonic clock is monotonic? time.clock_info('steady')['monotonic'] looks more natural, but I don't remember why we should not use the term "steady".

Well, the PEP mentions something like that in the "One function, no flag" section. But you don't seem to like it. (In general the alternatives section could do with reasons for rejection or at least pros and cons for each alternative.)

I was concerned by the fact that time.monotonic() may become not-monotonic between two calls, but I changed my mind. I agree that it should not occur in practice. So always fallback and add a way to know if the monotonic clock is monotonic now sounds like the best API to me.

Victor

More information about the Python-Dev mailing list