Python 3.15 benchmarks show up to 135x encoding speedups over 3.14, but Base16 slows down

Python 3.15 encodes data far faster than 3.14 in most of the standard binary-to-text formats, according to benchmark results published on dev.to — but one format moved backwards. Base32, Ascii85, Base85 and Base64 all posted large gains, with the biggest cases improving by two orders of magnitude, while Base16 came out about 22% slower than in the previous release.

The measurements come from a pyperformance 1.14.0 run on a single machine: an AMD Ryzen 9 7900 desktop with DDR5 RAM, a PCIe Gen4 NVMe drive and Windows 11, using 64-bit builds of Python 3.10 through 3.15.

The numbers

All values are in milliseconds; lower is better.

Benchmark	3.15	3.14	3.13	3.12	3.11	3.10
ascii85_large	11.62	797.9	709.0	772.3	643.8	759.2
base32_large	2.431	327.6	300.7	296.4	265.7	292.1
base85_large	4.293	272.4	252.9	258.8	230.1	259.2
base64_large	1.852	6.746	6.187	6.095	6.116	6.071
base16_large	5.767	4.714	22.52	23.08	23.89	23.71

The standout is base32_large, where 3.15 finishes in roughly 1/135th of 3.14's time (2.431 ms versus 327.6 ms). Ascii85 improved about 69-fold and Base85 about 63-fold on the large workloads. Base64's gain is more modest in relative terms — from 6.746 ms to 1.852 ms, roughly 3.6x — though it was already the fastest of the group in earlier releases.

Why the new encodings got faster

According to the dev.to analysis, the speedups come from rewriting the Base32, Base64, Ascii85 and Base85 encoders in C. Native implementations sidestep the bytecode interpreter's dispatch and type-checking overhead, keep intermediate values in CPU registers, and access memory in more predictable patterns — all of which matter for the shift-and-mask arithmetic these algorithms rely on. The author ties the 135x Base32 result directly to moving that loop out of interpreted Python.

The Base16 exception

Base16 is the outlier: base16_large took 5.767 ms on 3.15 against 4.714 ms on 3.14, a 22.3% regression. Two details soften the picture. First, Python 3.13 and earlier needed roughly 22.5–23.9 ms for the same benchmark, so 3.15 remains around four times faster than those versions — 3.14 was simply the high-water mark. Second, the source treats the cause as unresolved. Its working theory is that Base16 was not rewritten in C and still runs through the Python layer, with the slowdown possibly tied to allocator or object-layout changes in 3.15, or to 3.14 having used more efficient byte-level operations. These are hypotheses, not confirmed causes.

Caveats before upgrading

The results reflect one hardware and OS combination. The dev.to post cautions that Windows-specific behavior in the C runtime may not carry over to Linux or macOS, and that CPUs with smaller caches could widen the gap for the Python-side Base16 path. Its advice is workload-dependent: if hex encoding dominates your workload — as it can in blockchain tooling or embedded systems — staying on 3.14 for now may make sense. Otherwise, the gains elsewhere are large enough to justify evaluating 3.15, provided you measure your own code first.

Why it matters

Binary-to-text encodings sit in hot paths everywhere: data pipelines, attachment handling, token generation and storage formats. Turning a 327 ms Base32 operation into a 2.4 ms one changes what is practical in pure Python without native extensions or third-party libraries, and effectively removes encoding as a bottleneck in many data-processing workloads. The Base16 regression is the counterpoint: aggregate speedups don't guarantee per-format wins, and a version upgrade is only truly validated by benchmarking the workload you actually run, on the platform you actually deploy to.