Skip to content

Benchmarks

Every number here links to how it was produced. Anything not on this page is not a claim EmberMC makes.

R4 - Entity tiers via /ember bench, ~8,000 mobs

Reproducing R3 at higher density with the shipped command. One player anchoring about 8,000 ground-standing zombies (AI on, spread across the activation disc), /ember bench 10 cycling the tier and reading the entity phase over 10 s each. vanilla is the tiers off, the same box behaving as plain Paper.

Tier entity phase (10 s mean) vs vanilla
vanilla (= Paper) 51.09 ms baseline
balanced 17.99 ms 65% lower
performance 9.06 ms 82% lower
extreme 9.07 ms 82% lower

At this density vanilla is over the 50 ms budget (the server dipping under 20 TPS); the tiers pull it back to about 9 ms with room to spare. Reproduce it on your own load with /ember bench; the vanilla row is your own Paper baseline, not a figure from another machine.

R5 - Redstone re-validated live on the current build

A 31x31 dust plane (961 blocks) driven by a two-observer clock, force-loaded, no players; the engine switched with misc.redstone-implementation and a restart.

Redstone engine block-ticks phase (5 s mean)
Vanilla (Paper default) ~1.27 ms
Alternate Current (EmberMC default) 0.14 ms

About 9x lower, in line with R1.

R3 - Entity tiers: EmberMC vs Paper behaviour, one player, 2,037 mobs

A player standing in a disc of AI zombies (2,037 entities, spawning off) on the ember-folia box. The tier was switched with /ember reload on the same running server, same mobs, same second - so OFF is EmberMC ticking every in-range mob fully, exactly as regular Paper does, with none of the noise of comparing two containers.

Entity tick time across tiers

Tier entity-tick phase MSPT (5 s avg)
OFF - regular Paper behaviour 14.76 ms 16.7 ms
balanced 10.43 ms 12.0 ms
performance 9.19 ms 11.0 ms
extreme 5.67 ms 6.5 ms

Entity phase vs Paper: balanced -29 %, performance -38 %, extreme -62 %. And the promise held - every mob inside the player's full ring kept ticking fully at all four settings; only the outer ring was slowed. One run per tier, idle wandering mobs rather than a real farm; it shows the mechanism at the predicted scale, and the profiler is how you measure it on your own server.

R2 - Redstone: Paper vs Purpur vs EmberMC, same host

Three containers on one InterServer host, each idle apart from the rig, Temurin 25, 3.5 GB heap. Rig: a 31×31 plane of redstone dust (961 blocks) on smooth stone, driven by a two-observer clock feeding one corner, area force-loaded, no players. Yardstick: /mspt, 5-second window, read ~20 s after the rig was built.

Redstone cost: Paper vs Purpur vs EmberMC

Server Redstone engine avg max
Paper (stock) vanilla (default) 3.0 ms 16.7 ms
Purpur 26.2 (stock) vanilla (default) 2.5 ms 13.0 ms
EmberMC Alternate Current (default) 0.6 ms 1.2 ms

What this does and does not show. The engine difference is the story: Alternate Current is Paper's own redstone engine, shipped but off by default; EmberMC turns it on. Purpur's slightly lower vanilla figure is within the noise of three containers sharing a host. One run each.

Side finding. Every server's idle window showed a 0.3-1.9 s tick every five minutes - the autosave. Stock Paper's 10-second column read 1825.8 max. Only EmberMC's watchdog reported it; from the current build it is its own profiler phase, so the report says autosave rather than other.

R1 - Redstone engine, engine-vs-engine on one server

Same rig, same EmberMC server, switched live with misc.redstone-implementation + /paper reload, read on /ember profiler (block-ticks phase, 5-second window).

Engine mean p95
vanilla 2.20 ms 9.25 ms
Alternate Current 0.20 ms 0.74 ms

Pending

Entity tiers (Milestone 4) - needs a player standing in a 400-500 zombie pen while the tier is switched off / balanced / performance / extreme with /ember reload. With nobody online Paper deactivates every mob and there is nothing to measure. Will be recorded here when run.

Method

  • Same machine, same JVM, same flags, same world, same plugins, back to back.
  • Three runs per scenario per server once the harness exists; today's entries are single runs and say so.
  • Warm-up before measuring; a stated window; the exact build hash.
  • A result that cannot be reproduced from its description is not a result.