Chapter 14 · 13 July – 30 September
Against the reference compiler
Every released Raku++ binary, re-run on one machine in one sitting, against the Rakudo that was current on each release's day. This is the fairest picture of how the speed moved. Each release's own benchmark table was measured on whatever machine it had, and for a while with Rakudo emulated.
How it was measuredThe released
rakupp-macos-universal archive for each tag, checked against its published checksum, arm64 slice, on one Apple M3. Each kernel runs seven times; the first run is discarded and the fastest of the other six kept. Rakudo is built from source for each monthly release and assigned to Raku++ releases by date. The last point is a local build of v5.1.0. Hover any point for the release and its time.How to read them
- Two drops stand out. v3.6.0 to v3.7.0 is the value shrinking to 128 bytes and variables becoming slots (the values chapter): fib 536.4 → 369.8 ms, loopsum 206.2 → 97.2. v3.26.0 to v3.27.0 is object construction: 411.8 → 319.4 ms.
- Two rises. fib went from 736 ms at v0.5.1 to 898.5 at v1.2.6, while correctness came first. And v5.0.0 paid for 100% of Roast: fib 308.6 → 400.6, streq 237.3 → 335.2. The last chapter is the round that won most of it back.
- Compiled, Raku++ is faster than Rakudo on 16 of the 17 kernels. Interpreted, it still takes longer on
fib(1.3×),streq(1.4×),objects(1.8×) and a multi-dispatch kernel withwhereclauses (3.2×). - Startup is a few milliseconds against about 75: an interpreter that parses its program directly, against a VM that loads its runtime first. On one run that is nothing. On the two-hundredth run of an edit-and-regenerate loop, it is the difference you notice.
- Rakudo moves too. The dashed line steps at each monthly release, and 2026.09 made RakuAST its default front end. Its September rows come from a Homebrew bottle, which ran 2026.08 about 13% slower than a source build, so read that step with care.
The full table, with every kernel and the other engines, is on the dashboard.