os.stat vs Path.stat vs lstat: Localhost Lab

Intro — what this post promises

Stat many existing regular files via os.stat, pathlib.Path.stat, and os.lstat. This lab reports stats/s on Linux localhost.

It is not pathlib-vs-ospath path join / existence (lab 47). Here the only question is metadata syscall throughput.

Related links:

• 01shoppercove.compathlib vs ospath localhost lab
• 02shoppercove.comconfigparser vs json localhost lab
• 03shoppercove.comhtml escape vs manual localhost lab
• 04shoppercove.comqueue vs deque handoff localhost lab
• 05shoppercove.comstringio vs list join localhost lab
• 06shoppercove.comzlib vs gzip compress localhost lab
• 07shoppercove.comdifflib vs set ops localhost lab
• 08shoppercove.comgroupby vs manual localhost lab

Lab honesty (1 Oct 2026 IST): Python 3.13.5. Affiliates: 0. No Docker. Regular files only (no symlinks — so lstat ≈ stat).

Verdict up front (2000 files): os.stat ~605.1 kstats/s; os.lstat ~604.06; Path.stat reuse ~462.24; fresh Path(p).stat() ~148.94; open+fstat ~250.15.

Arms

Lab topology

n in {500, 2000, 8000} small files under results/tree/ · 7 rounds · p50
metric: stats/s = n / p50_s

Script: lab-evidence/106-stat-vs-path-stat/results/run_lab.py.

Lead table — 2000 files (p50)

Reused Path objects stay close to os.stat. Constructing a new Path per call drops to about ~25% of os.stat here.

Scale sketch (kstats/s)

Reading it

• Hot inventory loops: prefer os.stat or reused Path objects.
• Avoid Path(path_str).stat() inside tight loops (alloc tax).
• lstat ≈ stat on regular files; use lstat when symlinks matter.
• fstat needs an fd — fine if you already opened; expensive if open is only for metadata.

Pathlib still fine

For application code that stats occasionally, Path ergonomics win. This lab only bites when you stat thousands of paths per request/scan. Lab 47 remains the join/exists story — do not conflate.

DirEntry hint

If you are already walking with os.scandir, DirEntry.stat() can avoid extra path lookups. This lab isolates pure path-based stat calls — combine with the scandir lab when designing a tree walker.

Symlink footnote

We intentionally used regular files so lstat and stat should match. Introduce symlinks and stat follows while lstat reports the link inode — correctness diverges even when throughput looks identical on this fixture. Always choose the API for the symlink policy you want, not for a microbench dead heat.

Caching reality

Numbers here are warm-cache. First pass over a huge cold tree is dominated by disk/metadata FS latency; Python API choice shrinks to noise. Re-run on your storage class before setting SLOs off this localhost SSD/pagecache profile.

Pitfalls

• Benchmarking Path reuse when production builds Path fresh each time.
• Following symlinks unintentionally with stat vs lstat.
• Statting after every open when os.DirEntry.stat() from scandir would do (see scandir lab).
• Cold dentry cache vs warm — we warm with a warmup round.

Reproduce

python3 lab-evidence/106-stat-vs-path-stat/results/run_lab.py

Evidence: summary.json, summary.txt, tree/.

Batching stats behind a small worker pool rarely helps on pure metadata — the GIL and syscall path dominate before CPU parallelism pays. Measure before introducing threads solely for stat.

Limits

One Linux box. Local filesystem (not NFS). No symlink set. Warm page/dentry cache after warmup.

Takeaway

At 2000 files, os.stat ~605.1 kstats/s ≈ lstat; reused Path.stat ~462.24; fresh Path construction ~148.94. Keep Path objects or use os.stat in hot metadata scans.