perf_counter vs time vs monotonic Lab

Intro — what this post promises

Which clock should you call in a hot path: time.perf_counter, time.monotonic, or time.time? This lab measures ns per call on Linux localhost and records get_clock_info resolution plus the smallest positive back-to-back delta we saw.

Related links:

• lru_cache hit vs miss localhost lab
• logging vs print localhost lab
• deque vs list queue localhost lab
• itertools vs python loops localhost lab
• Why your average latency graph is lying (p50 / p95 / p99)
• copy vs deepcopy localhost lab
• struct pack vs to_bytes localhost lab
• set 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.