gh-150875: Speed up JSON string encoding for long ASCII strings

[gaborbernat]

json.dumps escapes each string by first scanning it one character at a time to size the escaped output (ascii_escape_size), after which write_escaped_ascii copies the string verbatim when nothing needs escaping. For a long string with no characters that need escaping, which is the common case for text values, log messages, and other long content, that per-character sizing scan is pure overhead before the verbatim copy.

This detects the no-escape case on the one-byte (ASCII/Latin-1) representation eight bytes at a time, so it returns the verbatim size after about one eighth of the work. It is the encode-side counterpart to #150872; the two touch different code paths and are separate changes.

What we do now (scalar, one code point at a time)

for (i = 0, output_size = 2; i < input_chars; i++) {
    Py_UCS4 c = PyUnicode_READ(kind, input, i);
    if (S_CHAR(c)) { output_size += 1; }   // ordinary char, needs no escaping
    else { /* compute the escaped width */ }
}

S_CHAR is printable ASCII except " and \, so a byte needs escaping when c < 0x20 || c > 0x7e || c == '"' || c == '\\'. For a long escape-free string this reads and tests every byte just to learn that the output equals the input plus two quotes.

What SWAR does (8 bytes at a time, in one register)

SWAR is "SIMD within a register": load 8 bytes into a single uint64_t and test all 8 lanes at once with ordinary integer ops.

for (; j + 8 <= input_chars; j += 8) {
    memcpy(&w, p + j, 8);
    mq  = haszero(w ^ (0x22 * 0x0101010101010101));   // any lane == '"' ?
    ms  = haszero(w ^ (0x5c * 0x0101010101010101));   // any lane == '\\' ?
    mlo = haszero(w & 0xE0E0E0E0E0E0E0E0);            // any lane < 0x20 ?
    mhi = (w & 0x8080808080808080)                    // any lane >= 0x80 ?
        | haszero(w ^ (0x7f * 0x0101010101010101));   // any lane == 0x7f ?
    if (mq | ms | mlo | mhi) { needs_escape = 1; break; }  // escape needed -> scalar
}
// no escape found anywhere -> output is the input plus two quotes
if (!needs_escape) return input_chars + 2;

haszero(v) = (v - 0x0101…) & ~v & 0x8080… lights the high bit of exactly the zero lanes, with no false positives or negatives. Broadcasting a byte (b * 0x0101…) and XOR-ing turns "equals b" into "is zero". The range checks < 0x20 and > 0x7e reuse the same idea. When all 8 lanes are ordinary, the loop advances 8 bytes; at the first lane that needs escaping it breaks and the existing per-character loop computes the exact size and does the work. A length guard keeps short strings (the common dict key) on the original loop, where the fast path's setup would not pay off.

These are the same 0x0101… / 0x8080… masks that Objects/unicodeobject.c and Objects/stringlib/find_max_char.h already use for ASCII scanning.

When and how this changes performance

json.dumps, current encoder versus this change:

Document shape	Effect
One long text field (~11 KB string)	5.3x faster
Many 200-character ASCII string values	3.1x faster
Realistic mixed records (short and medium strings)	1.3x faster
Short keys, strings that need escaping, the pyperformance document	no change
Strings with emoji or other non-Latin-1 text	no change (scalar path)

The gain scales with string length. The short-string guard keeps key-heavy documents unaffected; an earlier guardless version measured about 1.18x slower on a 2000-short-key document, which the guard removes.

Correctness

Output is byte-identical to the current encoder. Verified against the full test_json suite and a 199-case differential corpus that places each escape-relevant character (", \\, control chars, 0x7f, and non-Latin-1 characters) at every offset across the eight-byte window, in both ensure_ascii=True and ensure_ascii=False modes. Every output matched.

Benchmark

import json, pyperf
long_ascii = [("x"*200) for _ in range(200)]
text_blob  = {"body": "lorem ipsum dolor sit amet " * 400}
escaped    = [('a"b\\c\n'*30) for _ in range(200)]
short_keys = {f"k{i}": i for i in range(2000)}
mixed_real = [{"id":i,"name":f"user_{i}","email":f"u{i}@x.com","bio":"hello world "*10} for i in range(300)]
nonascii   = ["café 😀 中文 "*20 for _ in range(200)]
objs = {"long_ascii": long_ascii, "text_blob": text_blob, "escaped": escaped,
        "short_keys": short_keys, "mixed_real": mixed_real, "nonascii": nonascii}
runner = pyperf.Runner()
for n, o in objs.items():
    runner.bench_func(f"dumps/{n}", lambda o=o: json.dumps(o))

References for the bit tricks: Sean Anderson, Bit Twiddling Hacks (zero byte, byte equal to n, byte less than n); Henry S. Warren Jr., Hacker's Delight, 2nd ed., chapter 6.

It is not the SIMD parsing backend from #142915: it adds no intrinsics, no CPU detection, and no build configuration, and it does not depend on #125022.

Resolves #150875.

• Issue: Speed up JSON string encoding for documents with long string values #150875

[gaborbernat]

Added test_ascii_encode_long_string_paths to test_json/test_dump.py (runs under both encoders): a character needing escaping at every offset across the scan windows and the short-string guard, in 1-byte and wider strings, plus the no-escape verbatim fast path and \uXXXX escaping of non-ASCII.

[github-actions]

This PR is stale because it has been open for 90 days with no activity.

[gaborbernat]

@picnixz any appetite to get this merged or should we close it? Thanks!

[vstinner]

_Py_popcount32() has a 32-bit SWAR (SIMD Within A Register) implementation when built-in popcount() function is not available. It's just a few lines but it has long comments to explain it.

I'm not sure about this change, it looks to me quite complicated and hard to maintain. I'm not sure that it's worth it. But I don't consider myself as a json module maintainer :-)