Project O

Core capabilities

• Inspect a repository for structure, dependencies, tests, entry points, and environment
• Profile the running application for CPU time, call counts, and memory allocation
• Rank bottlenecks and reject candidates unsuitable for native conversion
• Generate the Rust implementation, PyO3 bindings, and a Python-compatible wrapper
• Compile through Maturin and capture build failures as evidence
• Prove behavioural equivalence through differential and property-based testing
• Benchmark end to end, including the cost of crossing the Python boundary
• Emit an inspectable patch and keep a rollback path to the original implementation

Why it exists

A Python function written to handle hundreds of records ends up handling millions. Every option at that point is partial: hand-optimising demands performance-engineering expertise, rewriting in Rust demands ownership, borrowing, bindings and packaging, and a general-purpose coding assistant will produce plausible Rust without ever establishing whether that function was the bottleneck. Even when the generated code compiles, nothing has shown it behaves like the original. Project O runs that whole sequence as one controlled pipeline instead of a fragmented manual project, on the principle that every optimisation must be measurable, behaviourally correct, and reversible.

Measurement before generation

The system profiles the application under real workloads rather than reading the source and guessing. Cumulative time, invocation frequency, allocation behaviour, and memory pressure produce a ranked list of candidates, and then most of them are rejected. A function that is slow because it waits on a database, a network, or a file will not get faster in Rust, and functions leaning on generators, dynamic imports, runtime reflection, monkey patching, or mutable global state are flagged as unsafe to convert. What survives is deterministic CPU-bound work with well-defined inputs, such as parsers, encoders, numerical loops, and transformations, where native execution actually pays.

Compilation is permission to begin testing

A generated function can compile perfectly and still be wrong. Verification sends identical inputs to both implementations and compares return values, types, exceptions, mutated arguments, side effects, output ordering, and numerical precision, using the project's existing tests alongside generated ones, with property-based testing, boundary values, empty and invalid inputs, large inputs, and encoding edge cases. The Rust version is rejected if it fails to preserve behaviour. Success is never defined as the code having built.

Benchmarking that counts the boundary

A Rust function can execute its own arithmetic quickly and still lose the gain converting Python objects into Rust structures at the boundary. Benchmarks are therefore end to end, covering execution time, throughput, latency distribution, peak memory, allocation behaviour, and performance across input sizes and after warm-up. Each one runs over multiple iterations with variance recorded, so a real improvement can be told apart from measurement noise. If the extension is not meaningfully faster in practice, it is not recommended. When it is, the change arrives as an inspectable patch with the original implementation preserved behind a rollback path.

Where it stands

The architecture, workflow, safety boundaries, CLI structure, and verification model are defined, and the system is in active development toward a user-facing enterprise developer tool. Performance claims are deliberately withheld until reproducible benchmarks exist across real Python projects, which is the same standard the tool applies to the code it generates.