Supported Workloads

Across 71 measured workloads in the canonical 2026-09-13 run, 54 ran faster under pyvorin-native 1.0.9 than under CPython and 17 ran slower. The pattern between those numbers is not random: the winners share a shape, and so do the losers. This page lays out both sides from measured per-category results, then shows the two commands that answer the only question that matters for your code: which side of the table your workload sits on.

What accelerates

The top of the table is dominated by pure-Python, CPU-bound inner loops — arithmetic and object work that stock CPython executes as a long stream of bytecodes. Per-category geometric means from the measured run:

The single best result was 202.8x on a trapezoidal-integral workload: a few dozen lines of pure-Python numeric code that CPython interprets instruction by instruction. That is the ground a native-code compiler is built to take. The mechanism is consistent across the winning rows: once types are stable and the loop body is pure arithmetic, object manipulation or image-pixel work, the compiler can vectorise and unroll where the interpreter must dispatch, box and reference-count every operation. Note also the spread inside categories — ETL spans 0.6x to 134.6x — because a category label describes code shape, not destiny. A table-driven ETL transform on stable numeric columns wins; one branchy transform over heterogeneous rows falls back. Category tables are a map of where to look, not a promise about any file.

What does not

The seventeen slower workloads cluster just as tightly, and their identity is instructive:

Look at what this code does: tokenising and splitting strings, routing URLs, inflating short byte sequences. It either runs inside C library routines — where CPython was never slow — or spends its time allocating and discarding millions of small objects, where the bottleneck is reference counting and allocation, not bytecode dispatch. There is little interpreted-loop work for the compiler to remove, and the compiled path's fixed overheads show through. The extreme cases, 0.05x, are micro-workloads whose entire runtime is smaller than the cost of compiling them. The honest conclusion: if your workload is string-, parsing-, I/O- or library-bound, pyvorin-native is unlikely to help and may cost a few percent. Do not buy it for that workload.

Language-level support

Support is decided per function, not per file. The frontend classifies what it finds and the router records the outcome — a function that compiles cleanly is COMPILED_FULL; one containing unsupported constructs is demoted to compatibility execution with the reason recorded, and its callers inherit that taint through the call graph. In our verification runs, plain numeric functions compiled full with the oracle passing, while a function containing yield was declined with an oracle-mismatch validation failure — the tooling discarding a claim it could not verify rather than shipping it. The per-feature detail comes from support -v, which names the feature and the consequence, as captured on our test file:

add      COMPILED_PARTIAL   1
  - Yield (add): Unsupported feature encountered;
    function executes in compatibility mode

Two reading notes on that output, both learned from staring at real reports. First, treat the unsupported count as a pointer to investigate, not a verdict — on the 1.0.9 build the verbose label can misattribute the feature name, so confirm against the compile report before restructuring working code. Second, the demotion is per function: a file with one generator does not lose its loops, and the compile report will show exactly which functions stayed full. Unsupported imports behave differently from unsupported constructs: an import in the unsupported tier raises ImportPolicyError at the frontend, fast and loud, where a construct demotes its function and gets logged. The full mechanics are on the unsupported code and fallback page.

Check your own code

Two commands answer the workload question for your code, both verified against the installed build:

# Per-function verdicts and unsupported-feature counts
python -m pyvorin support your_script.py
# add        COMPILED_PARTIAL   1
# - Yield (add): Unsupported feature encountered; function executes in compatibility mode

# Then measure, with correctness checked against CPython
python -m pyvorin bench your_script.py --json

Read support first, bench second. Support tells you whether the functions you care about are on the native path at all; bench tells you what that path is worth on your hardware, against your data, with compilation time reported separately from steady-state timing so you can judge amortisation yourself. Add inspect when you want the one-line summary for a dashboard — Native eligible over total, Risk level — and assess when the file is an ETL transform and you want the compatibility verdict with per-finding line numbers. On a workload of any size this takes minutes, and it will tell you more than every table on this page — the tables describe a suite, your measurement describes your program.

Choosing where to spend effort

The workload tables suggest a strategy; profiling confirms it. Our practice, after running these suites repeatedly: start from your own profile, not from the category table above. Find the function that dominates runtime, run support on the file that contains it, and let the verdict decide. If it compiles full, benchmark and keep it. If it is demoted, read the recorded reason — sometimes a small refactor (hoisting a generator out of a hot loop, replacing a dynamic call with a plain function) moves a function onto the native path, and that refactor is usually worth more than any compiler flag. If the function sits in a losing category, close the tab and profile the next one. The worst adoption programme we have seen treated the 42x object-manipulation column as a target and compiled everything in sight; the best one spent the same effort on six functions that a profiler had already named.

Where to go next

• Benchmarks — the full per-workload table these category figures come from.
• Quick start — install and run support on your first file.
• Unsupported code and the fallback path — what the demotion record means and when it is fine.
• Correctness validation — how the bench oracle check keeps the fallback honest.

Last reviewed 8 July 2026 against the canonical 2026-09-13 benchmark artefact (71 workloads, memory caps fixed and active, quiet host) and pyvorin-native 1.0.9 installed at /root/pvfinal. Every figure on this page was extracted from the artefact, not typed by hand; the support command output was captured from a real run.