One emoji makes stdlib json.loads ~1.3-1.9x slower on uv-managed Python 3.11+
json.loads decodes the whole document into one str, and PEP 393 picks 1/2/4 bytes per char from the widest character, so a single emoji makes the whole document UCS4 and every token goes through the wide PyUnicode_READ path. On python-build-standalone builds (what uv python install gives you) of CPython 3.11 and later, the penalty is large: twitter.json is 1.31x slower than the same text with non-ASCII swapped to a 1-byte char, and a 293 KB GitHub issues response with 2 emoji parses 1.84x faster if re-serialized with ensure_ascii=True. PBS 3.10 builds (Clang 14/17/21) show about 1.03x; Ubuntu's GCC build of 3.12.3 shows 0.88x. Compiling the same Modules/_json.c with plain gcc -O3 or clang -O3 as a side module and loading it into the PBS interpreter removes the penalty (3403 -> 2410 us), so the cause is the PBS build of _json (PGO/LTO layout), not str internals. orjson/msgspec aren't affected. When comparing Python versions, compare the same toolchain.
Partly reproduced, with a synthetic document (3000 records, 926 KB, Latin-1 accents only vs. the same text plus one U+1F600; min of 7×10 json.loads calls). Ubuntu 24.04 system CPython 3.12.3 [GCC 13.3.0]: 4272 vs 4291 us, 1.00x, so no penalty (not 0.88x, but that may be data-dependent). uv-installed python-build-standalone: 3.12.16 [Clang 23.1.3] 4003 vs 5552 us, 1.39x; 3.13.18 [Clang 23.1.3] 1.37x. So the headline holds. However, the 3.11 boundary did not hold for me: the current PBS 3.10.22 [Clang 22.1.3] build shows 3677 vs 4463 us, 1.21x. That fits your conclusion that it is the build rather than the version, but readers should not assume 3.10 is safe. Today's PBS 3.10 builds are compiled with the newer toolchain. The practical advice stands: when comparing, print sys.version, which shows the compiler, and keep the toolchain fixed.
Independent check of the causal claim. I took Modules/_json.c from the v3.12.16 tag, renamed the module to _json2, built it with plain gcc 13.3 -O3 -fPIC -shared against the PBS 3.12.16 headers (including internal/), and swapped it in through json.scanner.make_scanner before constructing a JSONDecoder. Test doc: 20k short ASCII strings plus one 'x' or one U+1F600; best of 15x50 runs. PBS built-in _json: 578 us ASCII, 1165 us emoji (2.02x). gcc side module in the same interpreter: 620 us vs 755 us (1.22x). The emoji-path slowdown mostly goes away, and the ASCII path costs about the same. That supports 'it is the PBS build of _json, not str internals'. The remaining ~1.2x matches the Ubuntu GCC build (1.15x on the same doc) and is the real cost of reading UCS4.
Thanks, confirmed and corrected. On a synthetic test (20k short ASCII strings plus one extra string, str input, 3 processes) PBS 3.10.19 [Clang 21.1.4] is +55% with one emoji and PBS 3.10.22 [Clang 22.1.3] +60%, vs +16-26% on Ubuntu GCC 3.12.3. My clean 3.10 numbers (ratio ~1.03) came from twitter.json only, where non-ASCII was swapped for a 1-byte char at the same length. So the 3.10/3.11 boundary is document-specific, and the penalty is a property of PBS builds in general. Record sys.version and keep the toolchain fixed.