[Python-Dev] PEP 564: Add new time functions with nanosecond resolution

Victor Stinner victor.stinner at gmail.com
Tue Oct 17 19:14:31 EDT 2017


I updated my PEP 564 to add time.process_time_ns():
https://github.com/python/peps/blob/master/pep-0564.rst

The HTML version should be updated shortly:
https://www.python.org/dev/peps/pep-0564/

I better explained why some functions got a new nanosecond variant,
whereas others don't. The rationale is the precision loss affecting
only a few functions in practice.

I completed the "Annex: Clocks Resolution in Python" with more
numbers, again, to explain why some functions don't need a nanosecond
variant.

Thanks Antoine, the PEP now looks better to me :-)

Victor

2017-10-18 0:05 GMT+02:00 Victor Stinner <victor.stinner at gmail.com>:
> Antoine Pitrou:
>> Why not ``time.process_time_ns()``?
>
> I measured the minimum delta between two clock reads, ignoring zeros.
> I tested time.process_time(), os.times(), resource.getrusage(), and
> their nanosecond variants (with my WIP implementation of the PEP 564).
>
> Linux:
>
> * process_time_ns(): 1 ns
> * process_time(): 2 ns
> * resource.getrusage(): 1 us
>    ru_usage structure uses timeval, so it makes sense
> * clock(): 1 us
>    CLOCKS_PER_SECOND = 1,000,000 => res = 1 us
> * times_ns().elapsed, times().elapsed: 10 ms
>    os.sysconf("SC_CLK_TCK") == HZ = 100 => res = 10 ms
> * times_ns().user, times().user: 10 ms
>    os.sysconf("SC_CLK_TCK") == HZ = 100 => res = 10 ms
>
> Windows:
>
> * process_time(), process_time_ns(): 15.6 ms
> * os.times().user, os.times_ns().user: 15.6 ms
>
> Note: I didn't test os.wait3() and os.wait4(), but they also use the
> ru_usage structure and so probably also have a resolution of 1 us.
>
> It looks like *currently*, only time.process_time() has a resolution
> in nanoseconds (smaller than 1 us). I propose to only add
> time.process_time_ns(), as you proposed.
>
> We might add nanosecond variant for the other functions once operating
> systems will add new functions with better resolution.
>
> Victor


More information about the Python-Dev mailing list