[Python-ideas] Add time.time_ns(): system clock with nanosecond resolution

[Antoine Pitrou]

On Sat, 14 Oct 2017 10:49:11 +0300
Serhiy Storchaka <storchaka at gmail.com>
wrote:

> 13.10.17 17:12, Victor Stinner пише:
> > I would like to add new functions to return time as a number of
> > nanosecond (Python int), especially time.time_ns().
> > 
> > It would enhance the time.time() clock resolution. In my experience,
> > it decreases the minimum non-zero delta between two clock by 3 times,
> > new "ns" clock versus current clock: 84 ns (2.8x better) vs 239 ns on
> > Linux, and 318 us (2.8x better) vs 894 us on Windows, measured in
> > Python.
> > 
> > The question of this long email is if it's worth it to add more "_ns"
> > time functions than just time.time_ns()?
> > 
> > I would like to add:
> > 
> > * time.time_ns()
> > * time.monotonic_ns()
> > * time.perf_counter_ns()
> > * time.clock_gettime_ns()
> > * time.clock_settime_ns()
> > 
> > time(), monotonic() and perf_counter() clocks are the 3 most common
> > clocks and users use them to get the best available clock resolution.
> > clock_gettime/settime() are the generic UNIX API to access these
> > clocks and so should also be enhanced to get nanosecond resolution.  
> 
> I don't like the idea of adding a parallel set of functions.
> 
> In the list of alternatives in PEP 410 there is no an idea about fixed 
> precision float type with nanoseconds precision. It can be implemented 
> internally as a 64-bit integer, but provide all methods required for 
> float-compatible number. It would be simpler and faster than general 
> Decimal.

I agree a parallel set of functions is not ideal, but I think a parallel
set of functions is still more appropriate than a new number type
specific to the time module.

Also, if you change existing functions to return a new type, you risk
breaking compatibility even if you are very careful about designing the
new type.

Regards

Antoine.