Benchmarks
Dragon vs Rust · best-of-3 · all -O2 · same machine
| Benchmark | Dragon | Rust | Verdict |
|---|---|---|---|
| Fibonacci (recursive, n=42) | 0.848s | 0.986s | Dragon 1.16× faster |
| Mandelbrot (float, 1600², 100 iter) | 0.421s | 0.452s | Dragon 1.07× faster |
| Sieve of Eratosthenes (1M) | 0.007s | 0.006s | tie (noise) |
| String concat (10k) | 0.003s | 0.003s | tie (noise) |
| Object creation (1M) | 0.002s | 0.003s | tie (noise) |
| Parallel sum (8×30M fork-join) | 0.174s | 0.149s | Dragon 1.17× slower |
| Dictionary / hashmap (3M str-key ops) | 1.144s | 0.666s | Dragon 1.72× slower |
| Binary trees (alloc/GC churn, depth 14) | 0.255s | 0.095s | Dragon 2.68× slower |
Where we stand
We beat Rust on compute-bound work. Recursive integer math (fib) and tight float loops (mandelbrot) are where the LLVM backend is already at or ahead of rustc. On fib we also beat Go and Java, and trail C/C++ by only ~12%.
The three sub-10 ms rows — sieve, string concat, object creation — are noise, not signal. They finish in 2–7 ms, dominated by process startup rather than the workload. Worth noting: object creation at 2 ms means the old GC-tracking overhead no longer shows up at this scale.
Three gaps we're closing
- Binary trees (2.68× slower) — the worst, and pure alloc/free churn, so it measures the refcount runtime, not codegen. Every node is two atomic ops under mutexes. The acyclic-skip-tracking / escape-analysis work is the fix; binary-trees is the canary that moves when it lands.
- Dicts (1.72× slower) — string-keyed hashmap. We trail Rust, Go and Java here; the hash + string-key path in
DragonDictis the suspect, not the loop. - Parallel sum (1.17× slower) — the closest gap. Green-thread fork-join carries a little more overhead than Rust's threads; we still beat Java and sit near Go.
Bottom line
Faster than Rust on raw compute, even on the micro-benchmarks — and we lose on allocation-heavy (binary-trees) and hashmap (dicts) workloads. Per our first commandment (speed is king), the refcount/alloc path is the highest-leverage target, and it's what we're working on next. These numbers are re-run and updated as the runtime improves.