perf_counter vs time.time: Which Python Timer to Use?

Intro — what this post promises

Use time.perf_counter to measure elapsed time in Python: it is monotonic, so NTP adjustments cannot move it, while time.time is a wall clock that can step forward or back and belongs in logs and timestamps. Cost doesn't decide it, because perf_counter, monotonic and time all took about 58-60 ns per call on Python 3.13.5 (about 33 ns net of loop overhead), and only process_time was much slower at about 278 ns.

Related links:

• 01shoppercove.comlru_cache hit vs miss localhost lab
• 02shoppercove.comlogging vs print localhost lab
• 03shoppercove.comdeque vs list queue localhost lab
• 04shoppercove.comitertools vs python loops localhost lab
• 05shoppercove.comWhy your average latency graph is lying (p50 / p95 / p99)
• 06shoppercove.comcopy vs deepcopy localhost lab
• 07shoppercove.comstruct pack vs to_bytes localhost lab
• 08shoppercove.comset vs list membership localhost lab

Lab honesty (1 Oct 2026 IST): Python 3.13.5. 500,000 calls/batch. Affiliates: 0. Overhead includes the for loop; we also report net vs an empty xor loop. Resolution claims are observed min positive delta, not a kernel guarantee under load.

Verdict up front: perf_counter / monotonic / time are peers at ~58–60 ns/call. process_time is the outlier (~278 ns). Empty loop baseline ~25 ns → net timer cost ~33 ns. Prefer perf_counter for intervals; avoid time() for durations (wall clock can jump).

Clocks under test

Lab topology

N = 500000 calls / repeat, 7 repeats, p50
Also: empty xor loop; t1-t0 pair pattern
get_clock_info + min positive back-to-back delta

Script: lab-evidence/57-perf-counter-vs-time/results/run_lab.py.

Clock info (this box)

Reported resolution is 1 ns for all four via clock_gettime. That is the API’s claimed resolution — not “every call returns a new nanosecond.”

Lead table — call overhead (p50)

Resolution caveats

Observed minimum positive back-to-back delta (10k trials):

So: do not treat sub-100 ns interval measurements as meaningful on this box — call overhead and clock grain are in that band. For microbenchmarks, batch work and divide, or accept that noise floors matter.

time() can step backward/forward with NTP; never use it for elapsed = t1 - t0 in production timers. perf_counter (or monotonic) is the interval API.

Pitfalls

1. Timing a single call — overhead ≈ the thing you timed.
2. Using time.time for durations — wall clock, adjustable.
3. Trusting resolution=1e-9 as usable precision — see min +Δ.
4. process_time for wall latency — ignores sleep/IO wait; also slower to call here.

When to pick what

Reproduce

python3 lab-evidence/57-perf-counter-vs-time/results/run_lab.py

Evidence: /workspace/lab-evidence/57-perf-counter-vs-time/results/.

Closing

Timer calls cost tens of nanoseconds. On this box perf_counter ≈ monotonic ≈ time at ~58 ns/call; process_time ~278 ns. Net after an empty loop ~33 ns. Use perf_counter for intervals; batch when measuring work near that floor.

FAQ

What is time.perf_counter?

Python's high-resolution monotonic clock for measuring intervals. On this Linux box it used clock_gettime(CLOCK_MONOTONIC) with a reported resolution of 1 ns.

Why not use time.time() for durations?

time.time is wall-clock time and can jump when NTP adjusts the clock, so t1 - t0 can be wrong. Use perf_counter or monotonic for elapsed time.

How precise is perf_counter really?

The smallest positive back-to-back delta observed was about 46 ns, so sub-100 ns timings are noise. Batch the work and divide instead of timing a single call.