Benchmarks

These are Pyvorin's own measurement results, reported in full: 71 workloads run against both CPython and Pyvorin on the same host, every one completing under both. 54 ran faster under Pyvorin and 17 ran slower. The geometric mean across all 71 was 3.16x. The median was 1.35x. The best result was 203x. The worst was 0.05x.

Most benchmark pages would not show you that last paragraph. We think it is the only honest way to publish results, because the slower cases are not noise — they form a pattern that tells you exactly what Pyvorin is for and what it is not. Below: the full distribution, the categories that win, the categories that regress, and the commands to measure your own code in the next ten minutes.

What we measured

The suite covers 71 small-to-medium workloads across 26 categories: numerical computing, ETL, compression, cryptography, parsing, simulation, image processing, graph algorithms, sorting, statistics, web request handling, string manipulation and others. Each workload is a self-contained Python program run on the same host under stock CPython and under Pyvorin with native compilation active. Compilation and execution happen locally; no source code leaves the machine.

Every workload completed under both configurations, and outputs are compared for correctness on every run. Earlier runs of this suite had five workloads that Pyvorin could not take through the compiler; in the current build those five all compile and run, which is why we re-publish the full table rather than cherry-picking the improvement.

The headline, in context

Across all 71 workloads: geometric mean 3.16x, median 1.35x, best 203x, worst 0.05x. Fifty-four workloads ran faster than CPython; seventeen ran slower.

Read the median before the mean. A median of 1.35x means the typical workload in this suite finished in comfortably under three-quarters of the CPython time — useful, not magical. The geometric mean of 3.16x is pulled upward by a group of very strong results: tight numeric loops that vectorise well. Both numbers are true; neither is a promise about your code. Only measuring your code is.

Where compilation wins

The categories at the top of the table share a shape: pure-Python, CPU-bound inner loops — the kind of code CPython executes as a long stream of bytecodes. That is the ground a native-code compiler is built to take.

The single best result, 203x, came from a trapezoidal integration workload: a few dozen lines of pure-Python numeric code that CPython interprets instruction by instruction. Compiled and vectorised, the same code finishes in milliseconds. Results like this are real, they are reproducible, and they are also the number we are least interested in leading with — they describe the best case, not the expected one.

Where it loses — and why

The seventeen slower workloads are the most instructive part of the dataset. Their categories:

Look at what these workloads do. Routing and parsing URLs, cookies and query strings. Tokenising CSV and log lines. Compressing short byte strings. This is code that spends its time either inside C library routines (where CPython was never slow) or building and discarding millions of small Python objects (where the bottleneck is allocation and reference counting, not bytecode dispatch). There is little interpreted-loop work left for a compiler to remove, and the compiled path's fixed overheads — guard checks, boxing — can show through. The worst cases, at 0.05x, are micro-workloads so small that compilation overhead dwarfs the loop itself; a Game of Life simulation in the same suite runs 154x faster. Same suite, opposite ends — which is exactly why suite-level marketing numbers are meaningless and per-workload measurement is the only sane basis for a decision.

Two practical consequences. First, if your workload is string-parsing-, I/O- or library-bound, Pyvorin is unlikely to help and may cost you a few percent — the honest answer is that you should not buy it for that workload. Second, the compiler never changes your program's semantics to chase a number: where it cannot produce a correct, faster path, it declines and you keep CPython behaviour.

Measure your own workload

Every figure on this page comes from the standard benchmark command, run locally. The same command works on your code:

# See which functions Pyvorin can take natively
python -m pyvorin support your_script.py

# Benchmark an entrypoint function
python -m pyvorin bench your_script.py --function your_entrypoint --runs 5

# Machine-readable output for CI
python -m pyvorin bench your_script.py --json

--runs and --warmup control measurement length. --no-vectorize, --no-parallel and --no-pgo isolate the contribution of each optimisation stage if you want to understand where a speedup comes from. Timing covers steady-state execution; compilation time is reported separately so you can judge amortisation on your own schedule. Run python -m pyvorin bench --help for the full flag list.

On a workload of any size, this takes minutes. It will tell you more than every number on this page combined, because it runs on your hardware, against your data, with your Python version.

Reading these numbers honestly

Three cautions before quoting anything here.

One host, one date. These results come from a single benchmark run on a single machine. The shape of the distribution transfers better than any absolute figure. Treat this page as a map of what to expect, not a contract.

Suite geomean is not your speedup. A 3.16x suite geomean says nothing directly about your pipeline. It says that across many CPU-bound Python workloads, the typical result was around 1.35x with strong winners and a real tail of slower cases. Your position in that distribution depends on how much of your runtime is acceleratable pure-Python execution.

Speedup is not the same as savings. Shorter execution time converts to lower compute cost or higher throughput only where your spend scales with the accelerated workload. Batch jobs on auto-scaling infrastructure are the clearest case; a fixed-size monthly VM is not.

Where to go next

• Benchmark methodology — how the suite is run, how correctness is checked, and how timing quality is graded.
• Benchmarking correctly — the measurement mistakes that produce misleading numbers, and how to avoid them.
• Quick start — install Pyvorin and benchmark your first function.
• Unsupported code and the fallback path — what happens when Pyvorin declines to compile something, in detail.

Last reviewed 12 January 2026 against the full benchmark artefact dated 13 September 2026 (memory limits active, quiet host): 71 workloads, all completed under Pyvorin (54 faster, 17 slower than CPython). Figures on this page are extracted from the artefact, not typed by hand.