perf(sanitize): make clean text allocation-free on the hot path

[SamMorrowDrums]

Fixes #3117

Sanitization ran several allocating passes over every user-authored field regardless of content. FilterInvisibleCharacters converted the whole input to []rune and back, FilterCodeFenceMetadata split and rejoined every line, and bluemonday ran unconditionally — so benign text paid full price on every conversion.

Changes

FilterInvisibleCharacters is scan-first / copy-on-first-match. It skips runs of ASCII without decoding them (no filtered rune is ASCII, and no variation selector is either), then copies into a builder only from the first rune that actually changes. Clean input is returned as the original string with zero allocations. Contextual variation-sequence handling is unchanged, and invalid UTF-8 is still re-encoded to U+FFFD to match the []rune round trip it replaces.

FilterCodeFenceMetadata walks lines in place instead of strings.Split/Join, and returns the input untouched when no line changes. sanitizeCodeFenceLine also stops rebuilding a line whose info string is already normalized.

FilterHTMLTags skips bluemonday for provably inert input. The policy tokenizes as HTML and re-emits text through html.EscapeString, so anything it can rewrite must contain one of the five characters EscapeString touches (&, ', ", <, > — also the only way to open a tag, comment, doctype or entity), a byte the tokenizer rewrites (NUL → U+FFFD, CR folded into LF), or a byte outside ASCII that could be malformed UTF-8. The fast path accepts printable ASCII plus TAB and LF minus those five characters, which excludes all three. A loose <>& check would not be sufficient: " and ' are escaped, and CR/NUL are rewritten by the tokenizer.

Sanitize skips the second invisible/code-fence pass when HTML normalization returned its input byte for byte. HTML processing is the only stage that can introduce a character its input did not contain (entity decoding), so if it is the identity there is nothing new to find, and both filters are fixed points on the first pass's output.

Nothing here weakens filtering or broadens allowed HTML. Content that genuinely needs rewriting still goes through the full pipeline, and non-ASCII text still goes through bluemonday by design.

Equivalence evidence

pkg/sanitize/equivalence_test.go keeps a verbatim copy of the previous pipeline and diffs the new code against it:

• ~22k deterministic corpus cases — every existing regression input, every rune class the filters branch on across 11 templates, all adjacent interesting-rune pairs, and 20k seeded pseudo-random strings including raw bytes and invalid UTF-8.
• isHTMLInert checked against the live policy byte by byte (in isolation and in context) and over the whole corpus, plus 50k dense printable-ASCII strings drawn from an HTML-syntax-heavy alphabet.
• Explicit fixed-point tests for the early return: both filters are idempotent, and the fence filter never reintroduces filterable runes.
• Allocation contracts asserted with testing.AllocsPerRun, and a check that a list of known payloads still loses something.
• Two fuzz targets: FuzzSanitizeMatchesReferenceImplementation and FuzzHTMLInertIsPolicyFixedPoint. Ran ~5.7M executions locally with no divergence.

Benchmarks

Committed in pkg/sanitize/bench_test.go and pkg/github/minimal_types_bench_test.go. Intel Ultra 9 185H, -count=6, benchstat:

benchmark	before	after	Δ
Sanitize/TitleASCII	5.35 µs, 5.16 KiB, 14 allocs	114 ns, 0 B, 0 allocs	−97.9%
Sanitize/Comment1KiB	45.3 µs, 20.2 KiB, 16 allocs	1.27 µs, 0 B, 0 allocs	−97.2%
Sanitize/Body64KiB	2.47 ms, 1.25 MiB, 21 allocs	85.9 µs, 0 B, 0 allocs	−96.5%
Sanitize/CodeFenceBody	256 µs, 132 KiB, 107 allocs	83.1 µs, 57.7 KiB, 19 allocs	−67.5%
Sanitize/Body64KiBUnicode	2.72 ms, 1.22 MiB, 21 allocs	1.00 ms, 444 KiB, 13 allocs	−63.2%
Sanitize/AdversarialUnicode	29.2 µs, 14.2 KiB	13.6 µs, 6.75 KiB	−53.3%
Sanitize/AdversarialHTML	180 µs, 63.5 KiB	134 µs, 43.3 KiB	−25.9%
SanitizeIssuePage (30 × 2 KiB)	2.73 ms, 1.55 MiB, 929 allocs	82.5 µs, 0 B, 0 allocs	−97.0%
SanitizeCommentPage (100 × 1 KiB)	4.62 ms, 2.18 MiB, 1600 allocs	137 µs, 0 B, 0 allocs	−97.0%
ConvertToMinimalIssuePage (30 issues)	3.00 ms, 1.55 MiB, 959 allocs	88.6 µs, 1.88 KiB, 30 allocs	−97.1%
ConvertToMinimalCommentPage (100 comments)	5.04 ms, 2.19 MiB, 1700 allocs	169 µs, 6.25 KiB, 100 allocs	−96.6%

All differences p=0.002 (n=6). The residual converter allocations are the struct and slice fields, not sanitization.

Projected overhead at 1,250 RPS

Per the issue's shapes, sanitizing one response:

shape	before	after
100 comments × 1 KiB	5.04 ms CPU, 2.19 MiB	0.169 ms CPU, 6.3 KiB
30 issues × 2 KiB	3.00 ms CPU, 1.55 MiB	0.089 ms CPU, 1.9 KiB

At 1,250 RPS:

• Comment-heavy: 6.3 cores → 0.21 cores, allocation 2.7 GiB/s → 7.6 MiB/s.
• Issue-heavy: 3.8 cores → 0.11 cores, allocation 1.9 GiB/s → 2.3 MiB/s.

Sanitization stops being a GC-bound cost centre for ordinary content. Non-ASCII bodies still pay for bluemonday (~1.0 ms per 64 KiB, down from 2.7 ms); extending the fast path past strict ASCII is deliberately left out of this change.

Validation

script/lint clean, script/test (race) green, script/generate-docs produces no diff.

[Copilot]

Pull request overview

Optimizes sanitization hot paths while preserving existing filtering behavior.

Changes:

• Adds allocation-free fast paths for clean text and inert HTML.
• Avoids redundant sanitizer passes and code-fence reconstruction.
• Adds equivalence, fuzz, allocation, and performance coverage.

Show a summary per file

File	Description
pkg/sanitize/sanitize.go	Implements sanitizer fast paths.
pkg/sanitize/equivalence_test.go	Verifies behavioral equivalence and invariants.
pkg/sanitize/bench_test.go	Benchmarks sanitizer workloads.
pkg/github/minimal_types_bench_test.go	Benchmarks representative converters.

Review details

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

• Files reviewed: 4/4 changed files
• Comments generated: 0
• Review effort level: Balanced