configparser vs JSON Config Load: Localhost Lab

Intro — what this post promises

Load equivalent app config (nested sections/keys) from INI via configparser vs JSON via json.load, many iterations. This lab reports loads/s on Linux localhost.

It is not json dumps compact vs indent (lab 75) and not json vs orjson/msgpack (lab 36). Focus: configparser vs JSON file load for settings.

Related links:

• 01shoppercove.comjson dumps compact vs indent localhost lab
• 02shoppercove.comjson vs orjson msgpack localhost lab
• 03shoppercove.comzlib vs gzip compress localhost lab
• 04shoppercove.comdifflib vs set ops localhost lab
• 05shoppercove.comgroupby vs manual localhost lab
• 06shoppercove.commethodcaller vs getattr localhost lab
• 07shoppercove.comqueue vs deque handoff localhost lab
• 08shoppercove.comstringio vs list join localhost lab

Lab honesty (1 Oct 2026 IST): Python 3.13.5. Affiliates: 0. No Docker. Same logical sections in .ini and .json.

Verdict up front (medium ≈ 22 sections / 306 keys, INI 6124 B / JSON 8751 B): json.load file ~22214.8 loads/s; json.loads ~30021.9; configparser.read file ~646.5; read_string ~628.1. JSON wins on speed/structure; INI wins on ops familiarity and comments.

Arms

Lab topology

small / medium / large section grids · 7 rounds · p50
metric: loads/s = 1 / p50_s

Script: lab-evidence/104-configparser-vs-json/results/run_lab.py.

Lead table — medium config (p50)

JSON file load is roughly ~34× configparser here.

Scale sketch (file load)

Gap stays large as configs grow — configparser’s section/key parsing is heavier than JSON’s C parser on this box.

INI vs JSON product tradeoffs

• INI / configparser: comments, interpolation, ops-familiar .ini, flat-ish sections (nested via naming).
• JSON: nested objects/arrays, types beyond strings (until you cast), ubiquitous tooling; no comments in strict JSON.
• Startup-once apps: either is fine. Hot reload / many workers parsing often: prefer JSON (or a binary/cache form).

Cold start context

Most services parse config once at boot. Even then, faster JSON shortens fork-heavy worker bring-up when each child re-reads settings. If you only edit config weekly, human ergonomics may beat a few thousand loads/s.

Reading it

• Prefer JSON when load rate or nested structure matters.
• Prefer INI when humans edit by hand and want comments.
• read_string vs read(file) is secondary next to format choice.
• Typed JSON still needs validation — speed ≠ schema safety.

Interpolation and comments

configparser supports interpolation and # / ; comments — JSON does not (without a non-standard super-set). If your ops team lives in annotated INI files, converting solely for a loads/s win may cost more in process than it saves at boot. Conversely, if configs are generated by machines, JSON (or TOML) is usually clearer.

Nested data shapes

Deep nesting is awkward in INI (fake hierarchy with section.subsection names). JSON objects/arrays map naturally to feature flags, allow-lists, and per-tenant blocks. That structural fit often matters more than the ~34× file-load gap measured on medium here.

Pitfalls

• Reloading INI on every request in a hot path.
• Comparing indented JSON dumps size to minified without noting it (fixtures here use indent=2).
• Assuming configparser preserves types (values are strings).
• Cannibalizing orjson benches — different question.

Reproduce

python3 lab-evidence/104-configparser-vs-json/results/run_lab.py

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

Limits

One Linux box. Synthetic section grids. Not TOML/tomllib, not YAML. Not multi-GB configs.

Takeaway

On a medium nested config, json.load ~22214.8 loads/s beat configparser.read ~646.5 loads/s. Pick JSON for speed/structure, INI for editable ops configs — not dumps-indent or orjson labs.