Python 3.15 vs 3.14, 3.13, 3.12 and Earlier Versions: Speed Comparison

How much has Python performance changed from version 3.6 to 3.15? A comparison of ten Python versions across 122 benchmarks shows substantial reductions in execution time for many workloads, alongside tests where an earlier release records the lowest mean. The results may help students, researchers and developers understand how Python performance varies across different workloads.

Test system and Python versions

The supplied test configuration is a desktop with an AMD Ryzen 9 7900 processor, DDR5 RAM and an M.2 PCIe Gen4 NVMe drive. All interpreters are 64-bit Python builds running on Windows 11.

Comparability note: the result files use three releases of the pyperformance benchmark suite: 1.0.6, 1.11.0 and 1.14.0. Different suite releases were needed because newer versions of pyperformance caused compatibility issues or errors with older Python interpreters. Older suite releases were used where necessary to run the benchmarks. A shared benchmark name does not establish that its implementation or dependencies remained identical. Cross-release differences therefore cannot be attributed solely to changes in the Python interpreter.

What changed in each Python version?

The following summaries describe selected features introduced in each minor release, from Python 3.15 back to Python 3.6. These features provide historical context – their availability does not establish that they were enabled or responsible for the benchmark results.

• Python 3.15: Introduced explicit lazy imports, unpacking in comprehensions and a new profiling package that includes the Tachyon sampling profiler.
• Python 3.14: Introduced template string literals (t-strings), deferred evaluation of annotations and standard-library support for multiple interpreters.
• Python 3.13: Introduced a redesigned interactive interpreter, an experimental free-threaded build and an experimental just-in-time (JIT) compiler.
• Python 3.12: Introduced type-parameter syntax, more flexible f-strings and support for a separate global interpreter lock (GIL) in each subinterpreter.
• Python 3.11: Introduced adaptive specialization in CPython, exception groups and except*, and asyncio.TaskGroup for managing related asynchronous tasks.
• Python 3.10: Introduced structural pattern matching with match and case, union type annotations using X | Y, and clearer error messages.
• Python 3.9: Added dictionary merge operators, type annotations using built-in collections such as list[int], and the zoneinfo module for IANA time zones.
• Python 3.8: Introduced assignment expressions with the walrus operator (:=), positional-only parameters and shared-memory support in multiprocessing.
• Python 3.7: Introduced dataclasses, context variables for managing contextual state, and the built-in breakpoint() function.
• Python 3.6: Introduced formatted string literals (f-strings), variable annotations and asynchronous generators.

How the benchmark results were calculated

The analysis reads the measured samples stored in the pyperf JSON files. Calibration and warmup entries are excluded. For each benchmark, it calculates the arithmetic mean of the measured values within each Python version. Stored timing values are already normalized per benchmark loop iteration.

Only benchmarks with a recorded Python 3.15 result are included. This excludes six tests: genshi_text, genshi_xml, sqlglot_normalize, sqlglot_optimize, sqlglot_parse and sqlglot_transpile. Missing results are shown as a dash (they are not treated as zero or as failed tests).

In the tables, bold green values marked ★ identify the lowest unrounded mean in that row. Lower execution time is better. Units are stated separately for each row: ms means milliseconds and µs means microseconds. Values are rounded to four significant figures for readability. These markings describe the observed means.

Python 3.6–3.15: selected benchmark results

Table 3 presents a selection of tests available on every version, with columns ordered from Python 3.15 back to Python 3.6. It includes examples of improvements as well as workloads where Python 3.15 is not the fastest. The full 122-test table appears later in the article, so the selection can be checked against the complete dataset. Wide tables can be scrolled horizontally.

The async_tree_io mean falls from 1418.8 ms on Python 3.6 to 558.8 ms on Python 3.15, a 60.6% reduction in recorded time. For json_dumps, the reduction over the same comparison is 46.1%. These are workload-specific observations, not estimates of how much faster every Python application will run.

The exceptions are equally useful. Python 3.11 records the lowest mean for json_loads, while Python 3.12 leads regex_dna. Python 3.6 has the lowest recorded startup means for the benchmark virtual environments used here – this does not establish that its interpreter initialization is intrinsically faster. For a short-lived command-line program, startup cost may matter more than the execution time of a long-running calculation. A single overall label such as “the fastest Python” would conceal these differences.

Interpreting the startup benchmark

The startup tests measure how long it takes to launch Python, run an empty command and close the process. A second test, labelled python_startup_no_site, skips the usual startup step that prepares installed packages for use. Startup time is especially relevant to small scripts that are launched frequently and finish quickly.

Python 3.6 has the lowest recorded startup times here, but the way Python is launched also matters. These benchmarks ran inside virtual environments: separate Python setups created for the tests. On Windows, newer versions can use an additional launcher to start Python from such an environment. This can add to the measured time. The official Python documentation describes this change, introduced in Python 3.7.2.

The commands used to launch Python are unchanged across the three pyperformance releases used here (1.0.6, 1.11.0 and 1.14.0). However, the recorded runs used different versions of pyperf, the library that launches the processes and measures their execution time: 2.5.0, 2.6.3 and 2.10.0, respectively. The workload was therefore the same, but the complete measurement setup was not.

Encoding benchmarks in Python 3.10-3.15

The encoding tests below have no recorded results for Python 3.6–3.9, so Table 4 compares only versions 3.10–3.15. All six use pyperformance 1.14.0. This removes the suite-release mismatch for this table.

Some recorded changes are particularly large. For base32_large, the mean is 327.6 ms on Python 3.14 and 2.431 ms on Python 3.15. Such differences merit a separate check of the benchmark implementation and execution environment before drawing conclusions about their cause. Python 3.14, meanwhile, has the lowest mean for base16_large – the newer version does not lead every encoding test.

Animated video charts

The animated video presents one benchmark at a time. Bar length is calculated as 100 × version mean ÷ the largest mean recorded for that test. The slowest measured result is therefore 100%. For instance, a result at 60% takes 40% less time than that result. It is not a 60% speed improvement.

Watch the full video:

Teal indicates faster results within a test, amber intermediate results and red slower results. Actual execution times appear alongside the bars. Each benchmark uses its own scale, so bar lengths should only be compared within the same chart.

AMD vs Intel: do the Python performance trends change?

For the broad conclusions of a Python-version comparison, the published AMD and Intel results suggest that processor choice need not substantially change the overall trend. The 2026 comparison of Python 3.14 and 3.15 reports a similar geometric mean speedup on both an AMD Ryzen 9 7900 desktop and an Intel Core i3-1315U mini PC. These figures summarize the relative improvement from Python 3.14 to 3.15 on each machine. They match after rounding, and the compared sets differ: 122 benchmarks on AMD and 118 on Intel.

The 2025 comparison of Python 3.10–3.14 also shows similar trends in several workloads across the two platforms. For example, moving from Python 3.13 to 3.14 reduces the async_tree_io time from 576 to 453 ms on AMD and from 580 to 448 ms on Intel: reductions of approximately 21% and 23%, respectively.

Taken together, these examples support similar relative performance trends on the tested systems. Absolute execution times and individual version rankings can still differ. The systems also have different memory configurations and form factors, so these comparisons do not isolate processor brand or establish statistical equivalence between AMD and Intel. Hardware-specific testing remains necessary when precise application performance matters.

Full comparison: all 122 benchmarks

The expandable table contains every selected benchmark and all ten Python versions. A star identifies the lowest recorded mean among the available values in that row. The same calculation, missing-value convention and rounding rules apply throughout.

Conclusion: benchmark the work you actually run

Python 3.15 records the lowest mean on most of the tests shared by all ten versions in this dataset. Earlier versions nevertheless lead several recorded workloads. Startup results are particularly sensitive to the launch environment, and the mixed benchmark-suite releases limit what can be inferred about interpreter changes alone. For students, researchers and developers, the practical lesson is to evaluate the workloads that matter to their own projects and report both the results and the conditions under which they were measured.