ext/standard: Add a fast path for ASCII in htmlspecialchars()

[ArtUkrainskiy]

This is the first part of #18126, split into a separate PR.

htmlspecialchars() currently calls get_next_char() for every input character and then checks the entity table. This is unnecessary for most ASCII input.

This changes the loop in php_escape_html_entities_ex() so that:

• get_next_char() is only called for bytes >= 0x80. ASCII is a single byte in all supported charsets.
• In htmlspecialchars() without ENT_DISALLOWED, ordinary ASCII bytes are copied directly until one of & " ' < > is found.
• get_next_char() is marked zend_always_inline.

The ASCII copy path is not used with ENT_DISALLOWED, since control characters still have to be checked, nor by htmlentities(), since HTML5 has entities for other ASCII characters too. The exception is htmlentities() with ENT_XML1 or a multibyte charset other than UTF-8: LIMIT_ALL reduces those to the basic entities, so they take the copy path as well.

get_next_char() is large enough that compilers kept it out of line. Forcing it inline removes the call overhead for non-ASCII input as well. This also follows @bukka's suggestion in #18126 to optimize the existing decoder rather than add another one.

Benchmarks

Release builds, master vs this PR:

Each row groups several inputs of the htmlspecialchars suite; the per-input numbers are in the report linked below.

htmlspecialchars() input	i7-13700H, GCC 13	Ryzen 9 5950X, GCC 15	instructions
short strings, 8–40 bytes	1.4–1.75× faster	1.4–2.5× faster	1.4–3.4× fewer
English text, 64 B – 64 KB	1.7–2.5× faster	2.7–3.8× faster	4.4–6.5× fewer
Markdown, JS, 4 KB	2.8× faster	3.7–4.1× faster	5.1–6.4× fewer
HTML, 1–64 KB	1.8× faster	2.5–2.9× faster	3.4–3.7× fewer
Russian (UTF-8), 1 KB and 64 KB	1.2–1.5× faster	1.15–1.2× faster	1.3× fewer
Chinese (UTF-8) 1–64 KB, Shift_JIS 1 KB, Big5 1 KB	1.2× faster	same to 1.2× faster	1.2× fewer
1 KB of only & / only "	1.4× / 1.2× faster	1.3× faster / same	1.2–1.4× / 1.1× fewer
cp1251 Cyrillic, 1 KB and 64 KB	same to 1.08× faster	1.3–1.7× faster	1.35–1.5× fewer

In Symfony Demo (benchmark/benchmark.php, callgrind), htmlspecialchars() and htmlentities() are called 221 times per request and account for about 1.3% of the instructions.

This patch reduces the instruction count for the whole request by 0.87% (39.48M → 39.14M), or 1.01% with the tracing JIT. The average htmlspecialchars() call goes from 2291 to 719 instructions.

The WordPress benchmark calls htmlspecialchars() only six times per request, so there is no measurable change there.

Other effects

htmlentities() shares the same loop. Apart from the cases above, it does not use the ASCII copy path, but avoiding the decoder for ASCII still makes it about 1.2–1.4× faster.

There is also a small improvement in json_encode() for non-ASCII strings. ext/json uses php_next_utf8_char(), which wraps get_next_char(cs_utf_8, ...). After inlining, the compiler can eliminate the charset switch and the unused decoders.

This increases the wrapper from 23 to 757 bytes and saves about 13–14 instructions per non-ASCII character:

json_encode() input	i7-13700H, GCC 13	Ryzen 9 5950X, GCC 15	instructions
Russian text	1.06–1.13× faster	same to 1.04× faster	1.1× fewer
Chinese text	1.10–1.13× faster	1.04–1.09× faster	1.1× fewer
ASCII text; json_decode()	same	same	same

ASCII input does not use this decoder, and json_decode() has its own scanner.

utf8_decode() and ext/xml use the same wrapper, but I did not benchmark them.

Verification

I compared the output against master for 20,000 random inputs using 13 flag combinations, 14 charsets, both functions, and both values of double_encode. The output was identical.

Full results and reproduction commands:

https://github.com/ArtUkrainskiy/php-src-bench/tree/main/reports/htmlspecialchars-ascii-fast-path

The ASCII copy loop still has one branch per byte. A SIMD version using zend_simd.h will be a separate PR.

[ArtUkrainskiy]

cc @devnexen @LamentXU123 — you've reviewed and merged the recent ext/standard optimizations, in case this one is in your area too.

[staabm]

//cc @nicolas-grekas as you also worked on performance of this function

[nicolas-grekas]

Thanks for the ping @staabm

@ArtUkrainskiy see #23957 which looks complementary.

[iliaal]

Fuzzed this against master under ASAN (14 charsets, all flag combinations, both functions, both double_encode values): identical output, no reports. One correction to the description: LIMIT_ALL clears all for htmlentities() with non-UTF-8 multibyte charsets or ENT_XML1, so those calls take the ASCII copy path too, which is fine.

[iliaal]

Forcing this inline also pulls it into the ambiguous-entity lookahead in find_entity_for_char(), which is cold. Do you have the overall html.o text size delta?

[ArtUkrainskiy]

Thanks for the fuzzing and the LIMIT_ALL catch, I'll fix the description.

html.o text grows by 2.2 KB (37,445 → 39,620): the big loop goes from 3.7 to 6.7 KB, the standalone get_next_char (1.5 KB) disappears, php_next_utf8_char grows to 757 bytes.

The lookahead copy is ~700 bytes of that. I tried keeping it out of line via a never_inline wrapper, but the wrapper alone is 1.5 KB, so the object only gets bigger, and that
build was slower across most of the suite (GCC reshuffles the registers in the big function). So I'd rather keep it as is.