Pyvorin vs Cython

Cython and Pyvorin both produce native code from Python source, but they demand opposite things from you. Cython, current in its 3.x series and released under the Apache 2.0 licence, is a source-to-source compiler: it translates a typed superset of Python into C, and you maintain that second language and its build toolchain forever. Pyvorin Native 1.0.9 takes the opposite bet — it compiles plain, unchanged Python scripts ahead of time through LLVM, locally, and falls back to ordinary CPython execution for anything it cannot take. The question that separates them is not speed. It is who owns the code and what you are willing to maintain.

As with every page in this series, there is no invented head-to-head benchmark here. Pyvorin's published suite measures Pyvorin against CPython across 71 workloads. What follows is a comparison of goals, constraints and workload fit — plus the commands to measure your own code on both sides.

What Cython is optimising for

Cython's project documentation is unambiguous about its purpose: it makes writing C extensions for Python as easy as Python itself, and it is "the ideal language for wrapping external C libraries, embedding CPython into existing applications, and for fast C modules". The language is a superset of Python — almost all Python is valid Cython — with optional static typing: cdef declarations, C types on variables and class attributes, direct calls into C functions, C++ class interaction and typed memoryviews over buffers.

The generated C compiles with all major C and C++ compilers and with CPython 3.8 and later. Two properties follow from that design. First, the output is portable C, which is why the scientific Python ecosystem — NumPy, SciPy, scikit-learn and thousands of packages on PyPI — ships Cython-built extension modules as prebuilt wheels. Second, the developer owns the type declarations, which means the developer owns the performance: annotated hot loops compile to near-C speed, while unannotated code compiles to something closer to ordinary CPython with overhead removed.

What Pyvorin is optimising for

Pyvorin optimises for the owner of a working Python application who wants native speed without a second language. You point it at an ordinary .py file; compilation happens locally and in-process, lowering through LLVM (via llvmlite) and linking against a local runtime. There is no C build step, no .pyx file, no setup.py, no per-module annotation pass, and no code changes at all — the published benchmark workloads are unmodified scripts.

Where the compiler cannot produce a correct, faster path, Pyvorin's router declines and runs the original code under honest CPython semantics, recording the fallback. Nothing crashes, and semantics are never traded for a number. The mechanism is detailed on the unsupported code and fallback page.

The constraints are real: Pyvorin requires CPython 3.11 or later, and the current shipped wheel targets CPython 3.12 on 64-bit Linux. It is also a commercial product with device-bound licence activation, tiered plans and 1%-sampled usage telemetry — none of which applies to Cython.

Where Cython is the better choice

You are writing a library for redistribution. This is Cython's home ground and always has been. If you publish packages to PyPI, a .pyx module compiled to C builds into wheels for every platform your users run, installable without any compiler on their side. There is no equivalent story for shipping Pyvorin-accelerated libraries to third parties; Pyvorin accelerates applications you deploy.

You are wrapping C or C++. Declaring external functions and operating on C++ classes is Cython's core competence. Pyvorin does not attempt it.

You need older or broader Python coverage. Cython's generated C builds against CPython 3.8 and later, including versions Pyvorin does not support (anything before 3.11), and Cython code is "mostly usable" on PyPy according to the project's own site. Pyvorin's support matrix today is CPython ≥3.11, one Linux wheel.

Budget is zero. Cython is free, Apache 2.0-licensed, with no activation, no tiers and no licence server. Pyvorin beyond its trial costs money — Starter £49 per month, Team £129, Business £399, Enterprise custom — and its licence check phones home to activate. For many teams that column settles the question on its own.

You need buffer-level or experimental-ABI work. Typed memoryviews over the buffer protocol, the CPython Limited API and free-threading support are all in Cython's documented feature set — the project notes that Limited API and free-threading support landed as experimental in Cython 3.1. Pyvorin offers nothing in this layer.

You want the compiler to be dumb and obedient. A cdef declaration means exactly what it says, and the generated C is inspectable with ordinary tools. Some engineers find that transparency worth the maintenance.

Where Pyvorin fits better

You own the deployment, not a build system. Every Cython project carries a second artefact — the .pyx sources, the build configuration, a C compiler in CI, a wheel-building matrix — that must be kept in step with the Python code forever. Pyvorin's maintenance surface is one command and a disk cache.

Your team is pure Python. Cython is a superset language with its own semantics edge cases; code review burden is real. Pyvorin requires no new literacy: the code being compiled is the code already in review.

Your hot code resists static typing. The benchmark categories where Pyvorin publishes its strongest results — object and OO manipulation (42.6x geomean across two workloads), simulation (11.8x), ETL transformations (4.5x), financial calculations (13.5x) — are exactly the dynamic, object-shaped code that static cdef annotation fights against. Cython can express such code, but the annotation work is where the hours go.

You need a guaranteed correctness story, not a compilation error. In Cython, unsupported or mistyped constructs surface at build time or as subtly changed semantics — you are compiling a different language. In Pyvorin, a function the compiler cannot take simply runs as the original Python, and the fallback is logged. For codebases where "it must behave identically" outranks "it must be fast", that is the decisive difference.

Regulation forbids source leaving the building. Pyvorin's compile path contains no network code; nothing is uploaded to be compiled. Combined with offline licence grace (24 hours on trial tiers, 72 hours on Basic and Professional, 90 days on Enterprise), that suits locked-down environments.

The build workflow in practice

A Cython project is a build project. The .pyx sources sit alongside the Python they accelerate, a build script or packaging backend drives the translation to C, a C compiler runs in CI, and the resulting wheels need a build matrix for every platform and Python version you support. Every change to the hot code path passes through that pipeline, and the pipeline itself becomes an asset someone must own. The compensation is total control: the generated C is portable, inspectable and yours. A Pyvorin deployment has almost no build surface. Install the package, activate the licence, run the benchmark commands. Compiled artefacts accumulate in a disk cache inside the install tree, keyed by source and compiler state, so repeat runs are warm without any artefact management. The compensation is narrower scope: one CPython version range, one platform today, and no deliverable wheel to hand to third parties.

The engineering judgement call

Here is the decision as it tends to arrive in practice. A library author maintaining a numerical package with a C dependency faces a clear answer: Cython, because the deliverable is a wheel, and wheels are Cython's native output. That is not a close call, and we would make it ourselves.

The application team is different. Their asset is a few hundred thousand lines of plain Python whose slowest parts are business logic — transformation loops, pricing, validation — running on infrastructure they control. Forking that codebase into .pyx files buys speed at the price of a permanent second codebase, reviewed by people who did not sign up to learn C semantics. For that team, "compile what exists, fall back honestly" is worth more than "rewrite for maximum control". Profile first, but weigh the maintenance, not just the microseconds.

Workload-fit matrix

What neither tool will fix

Neither compiler changes what your program waits on. In Pyvorin's published suite the slow categories are string manipulation (geomean 0.8x), parsing (0.9x), web request handling (0.9x) and compression (0.2x) — workloads bound by C libraries or by the allocation of millions of small objects, where removing the interpreter buys little. Cython can compile such code, but annotation effort spent there yields the least; its published strength is typed numerical loops. If the profile shows I/O or library time, fix the I/O first and revisit compilation afterwards. Profile first.

Measure your own workload

Both tools answer to measurement. For Pyvorin:

# 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

The Cython experiment is more involved by nature: extract your hot functions into a .pyx module, add cdef types, wire up a build, then benchmark the extension against the original. That setup cost is itself part of the comparison — it is what you are signing up to maintain. Keep both experiments honest in the same way: time the final artefact you would actually ship — the imported extension module, not an unrepresentative micro-harness — and check output correctness on every run. Whichever route you test, follow the discipline in benchmarking correctly, and read Pyvorin's full measured distribution — 48 of 71 workloads faster than CPython, 22 slower, worst case 0.05x — on the benchmarks page before quoting any number.

Where to go next

• Benchmarks — every measured CPython vs Pyvorin result, wins and losses included.
• Quick start — install Pyvorin and benchmark your first function in minutes.
• Pyvorin vs Numba — the decorator-based JIT alternative to rewriting.
• Pyvorin vs Nuitka — when the real goal is a deployable binary rather than faster functions.

Last reviewed 20 February 2026 against Pyvorin Native 1.0.9 (verified build of 12 September 2026) and Cython's published project materials at cython.org, the Cython 3.x documentation and the PyPI project page: Apache 2.0 licence, Python superset with optional static typing, generated C portable across CPython 3.8+ and major C/C++ compilers. No head-to-head Pyvorin–Cython benchmark exists; none is claimed on this page.