platform vs os.uname Inventory: Localhost Lab

Intro — what this post promises

Host inventory calls with platform.platform / platform.uname vs os.uname, plus node / machine / python_version. This lab reports ops/s on Linux localhost.

Related links:

• uuid4 vs uuid1 localhost lab
• path read text vs open localhost lab
• intenum vs int localhost lab
• dataclass asdict vs vars localhost lab
• tracemalloc snapshot localhost lab
• selectors vs select localhost lab
• literal eval vs json localhost lab
• signal vs event wakeup localhost lab

Lab honesty (1 Oct 2026 IST): Python 3.13.5. Affiliates: 0. Sample: Linux-6.12.94+-x86_64-with-glibc2.41.

Verdict up front (n=50000): platform.uname ~24411309 ops/s (cached after first use); os.uname ~2656012; platform.platform() ~9688571.

Arms

Seven rounds, p50.

Lab topology

n=50000 · 7 rounds · p50
metric: ops/s = n / p50_s

Script: lab-evidence/139-platform-vs-uname/results/run_lab.py.

Lead table (p50 ops/s)

Cache caveat (important)

CPython platform.uname() caches the result. Hot-loop ops/s look excellent (~24411309) because repeats are memory hits. os.uname() re-enters the kernel each call (~2656012). For a once-per-process banner, either is fine; for per-request inventory, cache yourself and do not spam os.uname.

Cold single-call platform.uname p50 was about 1.69 µs on a follow-up measurement after clearing _uname_cache.

Reading it for SRE work

• Process start fingerprint → call once, stash in a module global / metrics label.
• Heartbeats → reuse cached strings; do not rebuild platform.platform() every tick unless you must detect live kernel changes (rare).
• Prefer os.uname().release when you need the raw kernel release field without platform’s pretty formatting.
• Node name here: grok-bot-vm-357558404; machine: x86_64.

Pretty string cost

platform.platform() still cleared ~9688571 ops/s — fine for startup logs, wasteful inside a 10 k RPS handler. Emit it at boot; put stable labels on metrics.

Document whether your agent caches inventory so a “refresh host labels every request” experiment does not silently become a syscall storm via os.uname.

Field helpers

platform.node (~14813704 ops/s) and platform.machine (~14051804) are cheap enough for occasional labels, but still belong behind a process-lifetime cache in high-QPS services. Prefer structured fields over scraping the pretty platform.platform() string when building Alertmanager labels.

On multi-tenant nodes, treat hostname and uname release as possibly shared across containers — label carefully so dashboards do not imply stronger isolation than the runtime provides. Pair startup inventory with a unit test that freezes expected machine arch for your build matrix.

Pitfalls

• Benchmarking cached platform.uname against os.uname without stating the cache.
• Parsing platform.platform() strings instead of structured fields.
• Assuming container uname matches the host kernel story you expect.
• Calling inventory APIs in tight health-check loops.

Reproduce

python3 lab-evidence/139-platform-vs-uname/results/run_lab.py

Evidence: summary.json, summary.txt.

Limits

One Linux VM. Not Windows platform quirks, not live kernel upgrade detection.

Ship inventory as stable metric labels set once, not as freshly formatted strings on every scrape.

If a sidecar must detect kernel changes, poll os.uname on a slow timer and compare release strings explicitly.

Takeaway

Cache host inventory: platform.uname hot ~24411309 ops/s thanks to caching; os.uname ~2656012 hits the syscall each time. Call once at startup for banners; keep per-request paths free of inventory churn.