perf(decode): SIMD-accelerated backslash search in decode_string fast path

[membphis]

Background

decode_string currently scans for backslash escape sequences byte-by-byte in its inner loop. The structural scanner already uses SIMD to skip over long string interiors at the Phase 1 level, but Phase 2 decode_string pays the linear byte scan cost every time an escaped string is accessed.

Proposal

Add a SIMD probe inside decode_string (src/decode/string.rs) that searches for \ using AVX2 / NEON intrinsics (or falls back to memchr on scalar builds), jumping past unescaped runs in bulk rather than one byte at a time.

This mirrors the in-string fast path already present in the structural scanners (src/scan/avx2.rs, src/scan/neon.rs).

Expected impact

Meaningful win on payloads with many long escaped strings (e.g. embedded JSON, long base64 with \/ escapes). No effect on strings without backslashes (those already take the borrow-slice fast path and never enter the escape loop).

Notes

• Gate behind the same feature flags (avx2, neon) used by the structural scanners, or use memchr as a portable alternative that the compiler may auto-vectorize.
• Add a bench fixture or micro-benchmark with a string-escape-heavy payload to measure before/after.

[membphis]

Closing: measured 0% benefit on current make bench, ≤3% in realistic API scenarios

Quantified the proposed slow-path SIMD optimization against the existing bench suite plus a synthetic escape-density sensitivity test. Conclusion: not worth doing now.

1. Current bench fixtures never enter the slow path

• benches/fixtures/small_api.json: 0 backslashes
• benches/fixtures/medium_resp.json: 0 backslashes
• benches/lua_bench.lua synthetic payloads (100k–10m): string.rep(\"Q\", …) / string.rep(\"A\", …) — pure ASCII, no escapes

decode_string at src/decode/string.rs:10 always takes the memchr fast path and returns the borrowed slice. The byte-by-byte loop that #20 wants to SIMD-ify is never executed under make bench.

2. Sensitivity test: how much does the slow path cost in the worst case?

Synthetic payload: 200 × 1 KB strings, ~200 KB total. Varied the fraction of strings containing dense `\n` escapes; measured `qd.decode` (walks every string).

Escape density	qd.decode ops/s	Slowdown vs 0%
0% (all fast path)	56,070	—
10% strings escape-heavy	53,850	-4.0%
50% strings escape-heavy	35,217	-37.2%
100% strings escape-heavy (pathological)	24,694	-55.9%

So the slow path consumes up to ~56% of total `qd.decode` time, but only on a pathological 100%-escape payload.

3. Expected real-world impact of #20

Assuming a 4–6× speedup of the slow path from SIMD (realistic upper bound for NEON `vceqq_u8` + `vmaxvq_u8` skip + bulk `memcpy`):

Workload shape	Slow-path share	`qd.decode` improvement after #20
Current make bench fixtures	0%	0%
Typical API JSON (≤10% strings have escapes)	≤4%	≤3%
Embedded JSON / \\/-heavy base64	10–30%	8–24%
Pathological 100% escape	56%	~40%

4. Cost side

• Two SIMD backends (NEON + AVX2) + scalar fallback
• proptest cross-check parity (like tests/scanner_crosscheck.rs)
• Extra CI matrix work, unsafe surface, FFI panic-barrier discipline

Decision

Closing as not worth pursuing without evidence of a real escape-heavy workload. Reopen only with a fixture demonstrating > 20% escape density on production data — until then, the SIMD work in #17 (structural scan) and #32 (vqtbl) already captured the meaningful gains in this area.