Performance methodology

Benchmarks use release mode and Criterion. They contain no file or console I/O inside the measured loop. Raw Criterion state is build output under target/ and is not committed.

An orientation run on 2026-07-25 used Rust 1.97.1 on an AMD Ryzen 9 9950X under Linux 6.8.0-136. One Criterion process reported:

The Phase 5 orientation run used identical scalar inputs in Rust and the pinned C++ oracle, with both built in release mode on the same machine:

Mission-design kernels

Phase 6 measured each operation separately in the same Rust orientation run:

Ephemerides

Scalar and ordered-batch measurements were kept separate:

The matching C++/heyoka VSOP2013 harness measured first-time JIT costs of 63.96 ms at 1e-5 and 552.53 ms at 1e-9. Warm scalar calls took 166 ns and 5.908 µs, respectively. Enabling VSOP2013 increased the Rust release benchmark executable from 2.6 MiB to 7.0 MiB. ADR 0003 explains the data and cache decision.

Integration and dynamics

DOP853 selection

The Phase 10 decision harness produced these orientation measurements:

Cloning the cached C++ nominal integrator once cost 0.467 ms. In a same-profile candidate test, the selected facade took 15.431 µs and ode_solvers took 7.369 µs. The latter lacked the required root and sensitivity facilities and allocated per step, so nominal timing alone did not decide the dependency. ADR 0004 records the configuration, ranges, and risks.

Taylor integration

The fixed-system Taylor backend uses a matched-accuracy protocol because coefficient sweeps are not comparable to DOP853 right-hand-side calls. For one eccentric nondimensional revolution, Taylor’s speed relative to DOP853 was:

Taylor produced smaller final-state errors at every point. This is deliberately a narrow conclusion: Taylor is a high-accuracy option, not a low-accuracy replacement. The committed CSV also contains the 100- and 1,000-revolution rows; see High-accuracy Taylor integration.

All eleven built-in Taylor models now use incremental coefficient evaluators. Across the representative eight-model migration benchmark, replacing repeated full-series evaluation reduced warmed end-to-end propagation time by 6.45× to 28.97×. The linked Taylor guide gives per-model results and validation limits.

Evaluated models and controlled dynamics

The Phase 11 comparisons use the same initial state, final time, parameter, and 1e-12 tolerance.

The Phase 12 Rust schedule deliberately starts an independent DOP853 solve at each switch. Its timing includes all 32 restarts and confirms that integration does not perform a segment-count-dependent control search.

The Phase 13 propagation covers 1.2345 normalized time units. Rust uses a 0.01 maximum step to meet the recorded oracle tolerance, whereas the C++ Taylor solve has no equivalent limit. Treat this as an identified performance target, not as a like-for-like algorithm comparison.

Low-thrust legs

The Phase 14 comparison uses the same endpoints, masses, controls, duration, propulsion parameters, gravity parameter, and cut = 0.6. Construction and validation are outside both timings.

The Phase 15 comparison uses the same states, chronological controls, time grid, constants, cut, and 1e-12 tolerance, with no maximum step. Rust integrates every segment independently and uses fixed-size numerical dynamics Jacobians. Both operations therefore remain visible optimization targets.

Python batch throughput

The Phase 16 release-wheel harness used 20,000 items and the median of nine samples:

These measurements include Python input/output conversion; they are not Rust-core timings. They show why throughput-sensitive Python code should use the explicit batch APIs.

Interpreting the results

These are not cross-language speed claims. CPU frequency was not fixed and the run is not a substitute for distributions collected under controlled affinity and power settings. The Julian arithmetic result is small enough that compiler optimization and timer resolution dominate its interpretation. The C++ column is an elapsed average from five million calls rather than a Criterion distribution; it is included as the required same-input orientation baseline, not as a statistically controlled language comparison.

Reproducing the measurements

Run the maintained harness with:

cargo bench -p pykep-core --bench foundation
cargo bench -p pykep-core --bench elements
cargo bench -p pykep-core --bench propagation
cargo bench -p pykep-core --bench mission
cargo bench -p pykep-core --bench integration
cargo bench -p pykep-core --bench dynamics
cargo bench -p pykep-core --bench legs
python python/benchmarks/wrapper_overhead.py
cargo run --release -p pykep-lambert-optimization-benchmark
cargo run --release -p pykep-taylor-benchmark

Each benchmark group has a distinct scope:

The foundation anomaly loop keeps branch-heavy iterative work separate from arithmetic kernels. Scalar propagation and STM APIs use fixed-size arrays and perform no heap allocation. Ephemeris measurements distinguish initialization, scalar, high-precision, and batch paths. The integration final-state callback does not retain internal steps.

Standalone Lambert optimization

The standalone Lambert optimization benchmark ports the fixed easy.kttsp leg from pykep-lambert. It measures deterministic objective throughput and then applies the native fcmaes-core CMA-ES and BiteOpt implementations to wait time and time of flight. Its source revision, physical constants, decision bounds, penalty, optimizer budget, and seed are printed with every run; see tools/lambert-optimization-benchmark/README.md for the complete protocol.

Cross-language comparison policy

C++ comparisons are added only when both sides execute identical input data, validation policy, branch families, tolerances, and output work. Initialization and batch throughput are reported separately from warm scalar latency.

Release stabilization evidence

Phase 18 adds a protocol-matched 100-sample Rust/C++ distribution, bootstrap median confidence intervals, CI regression limits, allocation/cache/ vectorization profiles, and five-point Python batch scaling. Full results and environment limitations are in stabilization.md.