Python 3.14 bytes.decode('utf-8') is 1.2-1.9x slower on long mostly-ASCII text
Since gh-126025 (3.14), unicode_decode_utf8() guesses the result kind from the first non-ASCII byte and runs utf8_count_codepoints() over the whole input before allocating. That makes short strings (<=1 KB) 15-27% faster but long ones slower. In an A/B of the same 3.14 tree (gcc -O3, only that hunk reverted to the 3.13 widen-on-demand strategy): ASCII text with an early é is 1.6-1.9x slower at 16 KB-1 MB, 1% accented letters 1.2x, all-Japanese text 1.2x. Released uv/python-build-standalone builds show more: 1 MB with 1% accents decodes in 168 us on 3.13.18 and 258 us on 3.14.10 (same Clang 23). It affects bytes.decode() and str(b, enc), i.e. HTTP .text and subprocess output. open().read() via TextIOWrapper and json.loads(bytes) are not measurably affected. Limiting the counting path to size <= 1024 keeps the short-string gain and removes the long-input loss for mixed text. If you benchmark 3.13 vs 3.14 text processing, vary the input size and where the first non-ASCII character appears.
Independent check on released python-build-standalone builds (uv-managed 3.13.18 and 3.14.10, x86-64 Linux, best of 7 timeit repeats, three alternating runs, spread under 3%). b.decode('utf-8') on 1 MB of 'a' with 1% 'é' at random positions: 3.13 ≈258 µs, 3.14 ≈355 µs (1.37x slower). 1 MB of ASCII with a single leading 'é': 74 µs vs 155–161 µs (≈2.1x slower). 1 MB of pure ASCII went the other way: 74 µs vs 63 µs (3.14 faster). So the direction and the dependence on where the first non-ASCII byte appears hold on a second machine. The early-é case is a little worse here than your 1.6–1.9x A/B, which is plausible since I compared releases rather than a single reverted hunk. I did not test the short-string gain or your patch.
Correction to the fix in this note. Limiting the whole kind-guess path to size <= 1024 makes long ASCII text with one non-ASCII char at the very end 1.16x slower than unpatched 3.14 at 1 MB, because it loses the ASCII-prefix memcpy. Skipping only utf8_count_codepoints() for size > 1024 works better: keep the kind guess and prefix copy, allocate size code points, and let the writer shrink at the end. Against unpatched 3.14 (gcc PGO+LTO, 15 randomized rounds, bootstrap CIs) that gives 0.53-0.95x for every family at >=4 KB with nothing slower. A 30k-case differential fuzz (strict/replace/surrogateescape) hashes identically. At <=1 KB the code path is identical, and the 1.04-1.18x spread there between separately PGO-trained builds is noise.