Eryk Sun <eryk...@gmail.com> added the comment:
> What are the expected benefits from changing? Just a higher > resolution? I'm not sure that's worth anything if it's inaccurate. GetSystemTimePreciseAsFileTime() returns an accurate timestamp, which is the current system time plus the difference between the current value of the performance counter and its value when the system time was last updated. This can't be replicated simply with separate calls to GetSystemTimeAsFileTime() and QueryPerformanceCounter(). It relies on the following undocumented fields in the KUSER_SHARED_DATA record: BaselineSystemTimeQpc, QpcSystemTimeIncrement, and QpcSystemTimeIncrementShift. The system uses a similar procedure in QueryInterruptTimePrecise() to extend the precision of QueryInterruptTime(). Ditto for QueryUnbiasedInterruptTime() vs QueryUnbiasedInterruptTimePrecise(). > "GetSystemTimePreciseAsFileTime() has very little overhead; the new > function is even a little faster than GetSystemTimeAsFileTime(), a > call takes a few ten nanoseconds." The above claim was corrected back in 2014. GetSystemTimePreciseAsFileTime() is considerably more expensive than GetSystemTimeAsFileTime(). It costs about 10 times more on a system that supports an invariant TSC. It would be more expensive on an older system that use the chipset's HPET or ACPI PM timer. That said, I doubt this matters very much when calling time.time() in interpreted code. It's a difference measured in tens of nanoseconds. ---------- nosy: +eryksun versions: +Python 3.11 -Python 3.6 _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue19007> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
