Speed up dump(): buffered output and SWAR string escaping

[nlohmann]

What & why

dump() had two hot spots that mirror exactly what #5283 fixed on the parse side, so this PR reuses that PR's SWAR/UTF-8 primitives (detail/input/string_scan.hpp) to fix the serializer. Output is byte-for-byte unchanged on every input; only the path taken to produce it is faster.

Note on the base branch: this is stacked on claude/parser-performance-research-4hkdf8 (#5283), because it reuses that PR's string_scan.hpp scanner and validator. The diff here is only the serializer + tests; once #5283 lands on develop, this can be retargeted to develop unchanged.

The changes (each independent and reversible)

1. SWAR bulk string escaping (ensure_ascii == false) — dump_escaped() ran the UTF-8 DFA over every byte of every string and key, even for ordinary text with nothing to escape (the serializer twin of the parser's per-character get()). At a character boundary it now bulk-copies the longest run needing no escaping via string_bulk_run() — the same scanner + UTF-8 bulk validator the lexer's contiguous path uses — and drops to the byte-at-a-time DFA only for the first byte that needs individual handling (a quote, backslash, control char, or ill-formed/truncated UTF-8). For ensure_ascii == false, string_bulk_run()'s stop set is an exact match for the bytes dump_escaped copies verbatim, so escaping and error handling (including strict-mode error 316 position and message) are identical. Picks up JSON_USE_SIMDUTF for free.

2. Internal write buffer (devirtualization) — every structural character ({, ", ,, …) previously went straight to the output adapter through a virtual call. All writes now route through put_char/put_chars into a 1 KiB buffer flushed in bulk; the public dump() flushes once the top-level value is serialized (the recursive worker is split out as dump_internal). Runs larger than the buffer are written straight through, so large payloads are not copied twice. This is the dominant cost for object/array-heavy values.

3. ensure_ascii == true fast path — added find_ascii_copyable_run() (a SWAR scan stopping at ", \, < 0x20, 0x7F, and >= 0x80) so runs of printable ASCII are bulk-copied even when non-ASCII must be \u-escaped. 0x7F/DEL is a deliberate stop (it is escaped under ensure_ascii), which is why find_string_special() could not be reused directly here.

Measured gains

json::dump(), C++17, g++ 13 -O3, vs the pre-change serializer (representative synthetic data):

dataset	speedup
long ASCII strings, ensure_ascii=false	4.2×
long ASCII strings, ensure_ascii=true	4.1×
twitter-like objects	2.7×
pretty-printed objects	2.4×
dense CJK	1.8× (further headroom with JSON_USE_SIMDUTF)
integer arrays	1.1×

Verification

• Differential: dump output is byte-for-byte identical to the pre-change implementation across ~20k randomized byte strings plus curated edge cases (all escapes, control chars, 0x7F, valid multibyte, surrogates, overlong, truncated sequences), for compact/pretty and object/array output, both ensure_ascii settings, and all three error handlers, in C++11/17/20 at -O2/-O3.
• New serialization tests cover the write-buffer flush boundaries (>1 KiB strings, 2000-element arrays, 1100-deep nesting), escape and 0x7F handling, multibyte under both settings, and invalid-UTF-8 handling.
• Warning-clean under clang -Weverything and the gcc pedantic flag set; clang-tidy clean on the changed headers; make check-amalgamation clean.

---

• The changes are described in detail, both the what and why.
• If applicable, an existing issue is referenced. (none; follow-up to Speed up parsing of contiguous input: numbers, strings, and UTF-8 (with optional simdutf) #5283)
• The code coverage remained at 100%. A test case for every new line of code.
• If applicable, the documentation is updated. (no public API or option changes)
• The source code is amalgamated by running make amalgamate.

🤖 Generated with Claude Code

https://claude.ai/code/session_01XAYM1qhSA2FDaDcGfPW3fG

---

Generated by Claude Code