Entity performance
We ran AtlasSpigot and normal Paper on the same computer, same world, same settings, and timed both. Lower numbers are better. This was one test on one machine, so your results may differ — here's exactly how we did it.
Test environment
JVM flags (identical on both servers)+
-Xms4G -Xmx4G -XX:+UseG1GC -XX:+ParallelRefProcEnabled -XX:MaxGCPauseMillis=200 -XX:+UnlockExperimentalVMOptions -XX:+DisableExplicitGC -XX:G1NewSizePercent=30 -XX:G1MaxNewSizePercent=40 -XX:G1HeapRegionSize=8M -XX:G1ReservePercent=20 -XX:G1HeapWastePercent=5 -XX:G1MixedGCCountTarget=4 -XX:InitiatingHeapOccupancyPercent=15 -XX:G1MixedGCLiveThresholdPercent=90 -XX:G1RSetUpdatingPauseTimePercent=5 -XX:SurvivorRatio=32 -XX:MaxTenuringThreshold=1
Performance comparison — MSPT, lower is better
Baseline (300 entities)
Increased load (1,000 entities)
Chunk generation time
Wall-clock time to fully generate a fixed 101×101 chunk region (10,201 chunks) from the same seed, single run each. Lower is better.
World generation
What happened when we tested 26.2
Everything above is from Minecraft 1.21.4. We also ran the same test on 26.2, our newest and most heavily tuned build, and the result was too noisy to publish a number from. We are putting it here anyway, because a benchmark page that only shows the flattering runs is not worth reading.
Eight runs, alternating between AtlasSpigot and stock Paper so the machine warming up would affect both equally. AtlasSpigot averaged 10.94 ms per tick against Paper's13.15 — about 17% ahead. But the runs varied so much that the gap does not mean anything: Paper's own results ranged from 8.89 to 17.95, ours from 5.03 to 14.50, and one of the four matched pairs came out in Paper's favour.
The reason is the test machine, not the software. It is a laptop, and across eight back-to-back 4GB servers it heated up and slowed down: the last Paper run was 76% slower than the first, purely because it ran later. An earlier batch produced the opposite ordering entirely.
So: 26.2 is genuinely unmeasured, and we would rather say that than dress up a number the data does not support. Doing it properly needs a machine with a stable clock. The full raw output and analysis is inresults-26.2.txt.
Methodology
Both servers ran a small measurement plugin (source in the repo) that, after full startup, force-loads a fixed 21×21 chunk region around the test coordinates, spawns a fixed, seeded set of entities (a mix of zombies, skeletons, spiders, cows, and sheep — same seed, same positions on both runs), waits a warmup period for chunk generation and pathfinding to settle, then samples real MSPT via Paper's ServerTickEndEvent for 400 consecutive ticks (20 seconds) and writes the average. AtlasSpigot ran with its own documented tuned config (see What's tuned); Paper ran with its untouched defaults — this reflects what each project's config actually ships, not an artificially equalized config.
The chunk generation test uses a second, similarly small plugin: after startup it force-generates a fixed 101×101 chunk square around the same coordinates via World#getChunkAtAsync(x, z, true), timing wall-clock elapsed time from the first request to the last chunk completing. Same seed, same JVM flags, one run each, no players connected — a clean, repeatable measure of raw generation throughput rather than steady-state tick cost.
No numbers here are estimated, extrapolated, or copied from another project's own benchmark page. Every value above came from an actual run on this machine on the date this page was last updated. Re-running it yourself (same seed, same JVM flags, same plugins) should land close to these numbers on comparable hardware — meaningfully different results are worth reporting as an issue.