Direct overwrite vs temporary-file rename for publishing JSON
A timing baseline for two ways to publish a generated JSON artifact, with atomicity treated as the primary requirement.
The correctness boundary
What local cost appears when a generated file is written to a temporary path and renamed instead of overwritten in place?
Static-site generators, cache writers and feed publishers often update files while web requests are reading them.
A direct overwrite can expose partial content after a crash or concurrent read. Atomic replacement is a correctness feature, not merely a performance variant.
Temporary-file rename may add filesystem work, but it can prevent readers from observing a partially written destination on compatible local filesystems.
Measured evidence
What this run shows: Temporary file + rename led the happy-path timing run. Atomic visibility is still evaluated as a correctness guarantee rather than a performance trick. The slowest-to-fastest median spread was 43.63% on the measured host.
| Variant | Median | Middle 50% | Operations/s | Additional measure |
|---|---|---|---|---|
| Temporary file + renameFastest | 168.69 µs | 155.25 µs–177.62 µs | 5,928 | — |
| Direct overwrite | 242.30 µs | 232.81 µs–248.45 µs | 4,127 | — |
What could go wrong with a timing-only choice?
The timing winner does not decide the production design. If readers require complete old-or-new content, temporary-file replacement is usually worth a modest local cost.
Atomic rename assumptions must be validated for the target filesystem and deployment layout. The temporary file should reside on the same filesystem as the destination.
Implementation checks
- Use same-directory temporary files followed by rename for generated public artifacts.
- Fsync requirements should be evaluated separately for durability-sensitive systems.
- Keep temporary and destination files on the same filesystem.
How this boundary was tested
- Both variants publish the same compact JSON payload under an exclusive write lock.
- The atomic variant writes a sibling temporary file and renames it over the destination.
- The test runs on the package work directory; cross-filesystem rename behavior is not involved.
Open measured environment
- Measurement run
- 2026-07-22T15:23:56+00:00
- PHP
- 8.4.23 (cli)
- Operating system
- Linux 4.18.0-553.85.1.el8_10.x86_64
- Architecture
- x86_64
- Processor
- AMD EPYC-Rome Processor
- Reported host memory
- 15.02 GiB host total
- CLI OPcache
- 0
- PHP memory limit
- 1024M
- Loaded study extensions
- json, openssl, zlib, mbstring, pdo_sqlite
- Timing clock
- hrtime(true)
- Measured rounds
- 7
Scope and unresolved questions
- The benchmark does not simulate crashes or concurrent readers.
- Filesystem durability guarantees and network filesystems are outside scope.
Primary documentation
Use these documents to verify the required API, encoding or filesystem behavior. ASAMB supplies the local measurements, not the normative rule.
Inspect or rerun the evidence
The common runner and study-specific fixture are public so the result can be challenged on another PHP host.