122

I have some questions about the new functions time.perf_counter() and time.process_time().

For the former, from the documentation:

Return the value (in fractional seconds) of a performance counter, i.e. a clock with the highest available resolution to measure a short duration. It does include time elapsed during sleep and is system-wide. The reference point of the returned value is undefined, so that only the difference between the results of consecutive calls is valid.

Is this 'highest resolution' the same on all systems? Or does it always slightly depend if, for example, we use linux or windows?
The question comes from the fact the reading the documentation of time.time() it says that 'not all systems provide time with a better precision than 1 second' so how can they provide a better and higher resolution now?

About the latter, time.process_time():

Return the value (in fractional seconds) of the sum of the system and user CPU time of the current process. It does not include time elapsed during sleep. It is process-wide by definition. The reference point of the returned value is undefined, so that only the difference between the results of consecutive calls is valid.

I don't understand, what are those 'system time' and 'user CPU time'? What's the difference?

Improve this question
2
  • It's more duck to use time by function rather than implementation. I.e., use time.time() or time.monotonic() depending on what you want. Commented Oct 25, 2016 at 16:27
  • 3
    See this comment about how all cores used by a process are summed in time.clock and time.process_time, but child processes are not. Also see this discussion of precision (of course, varies by system). Commented Nov 29, 2018 at 8:49

1 Answer 1

Reset to default
159

There are two distincts types of 'time', in this context: absolute time and relative time.

Absolute time is the 'real-world time', which is returned by time.time() and which we are all used to deal with. It is usually measured from a fixed point in time in the past (e.g. the UNIX epoch of 00:00:00 UTC on 01/01/1970) at a resolution of at least 1 second. Modern systems usually provide milli- or micro-second resolution. It is maintained by the dedicated hardware on most computers, the RTC (real-time clock) circuit is normally battery powered so the system keeps track of real time between power ups. This 'real-world time' is also subject to modifications based on your location (time-zones) and season (daylight savings) or expressed as an offset from UTC (also known as GMT or Zulu time).

Secondly, there is relative time, which is returned by time.perf_counter and time.process_time. This type of time has no defined relationship to real-world time, in the sense that the relationship is system and implementation specific. It can be used only to measure time intervals, i.e. a unit-less value which is proportional to the time elapsed between two instants. This is mainly used to evaluate relative performance (e.g. whether this version of code runs faster than that version of code).

On modern systems, it is measured using a CPU counter which is monotonically increased at a frequency related to CPU's hardware clock. The counter resolution is highly dependent on the system's hardware, the value cannot be reliably related to real-world time or even compared between systems in most cases. Furthermore, the counter value is reset every time the CPU is powered up or reset.

time.perf_counter returns the absolute value of the counter. time.process_time is a value which is derived from the CPU counter but updated only when a given process is running on the CPU and can be broken down into 'user time', which is the time when the process itself is running on the CPU, and 'system time', which is the time when the operating system kernel is running on the CPU on behalf on the process.

Improve this answer
Sign up to request clarification or add additional context in comments.

19 Comments

Real-time runs at a fixed rate, CPU clocks vary widly. Using the CPU clock to measure code performance gives the best possible resolution (down to instruction scale). Limiting the CPU clock to a fixed sub-division of real-time restricts that precision pointlessly.
how would the OS know about the CPU frequency? about CPU low-power states? who to believe in multi-core systems? And what happens when the CPU is powered off? It is such a difficult task to manage, when having a dedicated, battery power realtime clock circuit is so easy.
@antox: for a better understanding, read this
@isedev: From your answer I understand that time.perf_counter and time.process_time were unitless, but the docs say that they are measured in fractional seconds. That means they can be used to measure time intervals in real world units, right?
"This type of time has no defined relationship to real-world time... a unit-less value ..." - Excuse me for my curiosity, but why? It is literally stated in documentation that return value is fractional seconds.
|

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.