Benchmarks
Every benchmark runs the release build on one machine: an i9-13900K with 24 cores and 32 threads, 48 GiB of memory and Windows 11. Each number below is a recorded run, with the commit it ran at, and each benchmark runs again with one command. CI runners are too noisy to compare, so none of these come from CI.
100 players
This one runs on every commit that might change the tick or the network. 100 bots join a flat world, 20 a second, then walk outward in their own directions so each keeps being sent new chunks, and chat to everyone every 10 seconds, for 45 seconds. View and simulation distance are 10. The numbers are the median of 5 runs.
| Windows 11 | Linux, WSL 2 | |
|---|---|---|
| Tick, mean | 0.419 ms | 0.472 ms |
| Tick, p99 | 1.112 ms | 1.259 ms |
| Tick, longest | 1.644 ms | 1.853 ms |
| Ticks a second | 20.00 | 20.00 |
| Tick while joining, mean | 1.164 ms | 6.135 ms |
| Joining, median | 549 ms | 552 ms |
| CPU time, all threads | 3.03 s | 2.92 s |
| Peak memory | 70.0 MiB | 68.3 MiB |
| Chunks sent | 80,251 | 80,362 |
The tick times come from the server itself, over the steady part of the run. A single run's mean moves by about 10% with whatever else the machine is doing, so a result more than 5% worse than the recorded one is run ten more times before anyone looks into it. Ticks while players join are slower on Linux than on Windows on the same machine, and the cause isn't known yet. The same load on Paper, Folia and Pumpkin is measured in Phase 8.
Recorded in bench/results/bots-windows.json at commit 565d961.
Joining and flying
Bots wait for the server, but a real client asks for chunks as fast as it can take them, so this one uses Mojang's own 26.3 client at render and view distance 32, on a new world. It joins, waits, and then flies straight ahead for 30 seconds. A relay between them counts, four times a second, how much of the circle of 32 chunks around the player the client has.
At 25 times vanilla's flying speed the client has nearly all of its view the whole way, and what it's missing is at the edge: the nearest chunk it doesn't have is 30 chunks away, at the median. At 100 times it flies 67 chunks a second. The circle ahead of it then needs more new chunks each second than 32 threads can generate, and within seconds the player has outrun them, while the server keeps sending 1,193 chunks a second.
The whole table
| 25× | 100× | |
|---|---|---|
| Joining, 95% of the chunks | 2.98 s | 2.98 s |
| Joining, all of them | 3.10 s | 3.09 s |
| Flight speed, blocks a second | 269.1 | 1,074.9 |
| Chunks sent a second | 1,116.9 | 1,192.8 |
| View the client had, mean | 97.9% | 12.5% |
| View the client had, least | 90.7% | 0.4% |
| Tick while flying, mean | 4.88 ms | 5.95 ms |
| Tick while flying, p99 | 14.89 ms | 11.37 ms |
| Memory, idle | 76.6 MiB | 76.6 MiB |
| Memory, one player still | 365.0 MiB | 366.1 MiB |
| Memory, at the most | 1,117 MiB | 1,126 MiB |
Recorded in bench/results/client-windows.json at commit 565d961.
Worldgen with data packs
C2ME publishes a benchmark that generates a world with Terralith and Terratonic, beside Paper and vanilla. Calcite runs it with its own pregen, and vanilla, Paper and C2ME run it with Chunky, on the same machine and set up as C2ME's is. Calcite made 1.64 times as many chunks a second as C2ME on one thread, and 1.28 times as many on 32.
32 threads · Calcite 1.28× the next fastest
chunks a second · higher is better
1 thread
8 threads
| threads | Calcite | C2ME | Paper | vanilla | Calcite's memory, MiB |
|---|---|---|---|---|---|
| 1 | 80.1 | 48.8 | 52.8 | 37.9 | 767 |
| 8 | 414.8 | 312.5 | 313.7 | 98.0 | 946 |
| 16 | 610.2 | 484.4 | 308.5 | 103.9 | 1,101 |
| 32 | 878.6 | 687.1 | 312.5 | 112.9 | 1,309 |
- The packs are Terralith 2.6.5+26.3 and Terratonic 3.0.31, on C2ME's seed, 114862964781274189.
- Each launch starts on a new world with a 512-block warm-up around the origin, then measures a 1,024-block radius around 1,000,000, 1,000,000: 16,384 chunks.
- The Java servers run on JDK 25 with C2ME’s flags and a 16 GiB heap touched up front, so their peak memory is that heap and isn’t compared.
- On a long run, vanilla with Chunky fills its heap, so it’s given vanilla’s own save-all flush every 120 seconds, which costs it about 8%. C2ME’s benchmark gives vanilla a patched Chunky that isn’t published.
- Calcite at 565d961. Vanilla on Fabric 0.20.1, Paper 26.3-238 and C2ME 0.4.2-alpha.0.115, each with Chunky 1.5.3, at 868e0a0.
- Paper used the 16 and 32 worker threads it was given, as its log says, and made no more chunks than with 8. Vanilla made about 100 a second at every count from 8 up.
- The rig checks a sample of 264 of the chunks Calcite generates with the packs, and every one has what must be vanilla’s.
- C2ME’s own benchmark uses a 3,072-block radius, which takes vanilla hours on one thread. This one is smaller, so the whole comparison takes about an hour and a half.
Recorded in bench/results/terralith-windows.json at commit 565d961.
Vanilla's worldgen
The same benchmark without the packs, through the whole server, the way a player's chunks are made: each chunk is generated, lit, saved to its region file and compressed, and kept until it's let go. The dotted line is the same runs at 868e0a0.
| threads | chunks a second | steady | at 868e0a0 | CPU time, s | memory, MiB |
|---|---|---|---|---|---|
| 1 | 150.6 | 153.0 | 136.3 | 149 | 498 |
| 8 | 1,014.1 | 1,147.8 | 832.1 | 181 | 644 |
| 16 | 1,559.4 | – | 1,286.4 | 224 | 762 |
| 32 | 2,022.1 | – | 1,689.8 | 272 | 915 |
The steady rate counts from 10% done to 90%. At 16 and 32 threads the run is over before there are two progress lines between those, so it has none.
Recorded in bench/results/worldgen-windows.json at commit 565d961.
Light
The rig runs its light probe on vanilla's server and on Calcite, 15 times each after a warm-up, on three workloads, and checks that the two engines give every block the same light level, from 0 to 15. They did in every run.
A flat world's light is the sky's, one level at a time, so there's little work either way. Terrain is where the difference shows.
Flat, 9×9 chunks · Calcite 1.1× as fast
Terrain, 7×7 chunks · Calcite 1.78× as fast
Terrain, 7×7 chunks, 5,000 edits relit · Calcite 1.6× as fast
Run by rig/runner/light_timing.py at commit 565d961. The results are in bench/README.md.
Running them
From the repo, with Python 3.10 or later and nothing else. Each one builds the release server with Calx first. The client benchmark needs a desktop with Minecraft 26.3 installed.
# 100 players py -I bench/run.py --record # a real client, joining and flying py -I bench/client.py --record # worldgen with the packs: Calcite, then vanilla, Paper and C2ME py -I bench/terralith.py --record py -I bench/others.py --record # vanilla's own worldgen py -I bench/terralith.py --no-packs --record # light, beside vanilla's engine py -I rig/runner/light_timing.py
bench/README.md has how each one is set up, and the history of every number. On Linux, use python3 in place of py. The site reads the results files when it's built, so a newly recorded run shows up here with the next deploy. What gets measured next