← back home · compare
rninja vs ninja
// The original build executor
ninja is the tool rninja drops in for. Same file format, same flags, same exit codes. The differences sit inside the executor: a content-addressed action cache, an async scheduler, and an optional remote cache. If a build is correct under ninja, it stays correct under rninja.
| Feature | rninja | ninja | Advantage |
|---|---|---|---|
| build.ninja format | Parsed unchanged | Authoritative | comparable |
| CLI flags (-C, -j, -k, -d, -t) | Mirrored, same semantics | Native | comparable |
| Action cache | Built-in (sled index + dedup blob store) | None | rninja |
| Scheduler | tokio async, IO + CPU aware | Single-threaded bookkeeping + -j workers | rninja |
| Remote cache | Optional, async-nng transport | None | rninja |
| Dispatch overhead on tiny graphs | Slightly higher (cache bookkeeping) | Minimal | ninja |
| Binary footprint | Larger (Rust + cache deps) | Smaller | ninja |
| Determinism guarantees | Identical to ninja (compatibility tests) | Authoritative | comparable |
| License | MIT | Apache-2.0 | comparable |
// pick rninja when
- ▸You have repeated incremental builds that recompile unchanged sources
- ▸You run CI pipelines and want to share artifacts across runs without standing up bazel
- ▸Your monorepo builds the same subgraph from multiple developer machines
- ▸You want the executor improvements without changing your generator (CMake, GN, Meson)
// pick ninja when
- ▸Your builds are already so fast that any extra bookkeeping is pure cost
- ▸You need the smallest possible binary on a constrained system
- ▸You prefer the smallest-possible-surface tool with zero optional features
Still deciding?
The cheapest experiment is the side-by-side: time ninja.orig target vs time rninja target on your real repo. Numbers settle the argument faster than marketing pages.