Why Minecraft rewritten in Rust can run faster than Java Edition

A Rust rewrite of Minecraft can be faster than Java Edition for two kinds of reasons. Some come from the language and runtime: native code with no virtual machine, so no garbage-collection pauses, no warm-up while the JIT compiles, and data laid out compactly in memory. The rest come from doing the work differently, and in Horizon’s case those design choices (worker threads, batched drawing, a modern graphics API) explain at least as much of the gap as Rust itself.

This piece explains both without the hype, then looks at what Horizon’s published benchmarks actually measured.

The Java side: what a JVM does for you, and what it costs

Minecraft: Java Edition runs on the Java Virtual Machine. Two of its features matter for frame rate.

Garbage collection. In Java you create objects and never free them yourself. A garbage collector periodically finds objects nothing points to and reclaims their memory. Modern collectors are clever and mostly run alongside your program, but they still need CPU time and, at moments, short pauses. In a game that has to deliver a frame every few milliseconds, a pause at the wrong time is a visible hitch. Minecraft creates a lot of short-lived objects, which keeps the collector busy.

JIT compilation. Java code first runs slowly, and the JVM compiles the hot parts to machine code while you play. That’s why a Java program often gets faster after a while. The flip side is warm-up: the first minutes can be less smooth than later ones.

Neither of these is a flaw as such. They make Java productive and safe. They just cost predictability.

The Rust side: what you get without a runtime

Rust compiles straight to machine code for your processor before you ever run it. Horizon’s performance docs put it simply: “There is no Java virtual machine, so no garbage-collection pauses and no warm-up while the code gets compiled as you play.”

Memory is freed when it stops being used. Rust tracks ownership at compile time. When a value goes out of scope, its memory is released right there, at a known point, so there’s no collector to schedule.

Memory layout is under control. In Java, most things are objects reached through references, each with a header, scattered around the heap. In Rust a struct holding numbers can be stored as just those numbers, side by side, and an array of them is one contiguous block. Processors love contiguous data: it fits in cache and reads fast. A block-heavy game like Minecraft benefits from that.

Threads with fewer footguns. Rust’s compiler refuses many kinds of unsafe sharing between threads. That makes it less risky to spread work over cores, which is where modern CPUs have spare capacity.

The part that isn’t about Rust

A rewrite lets you redo old design decisions, and Horizon’s docs list several:

• Work off the main thread. Chunks are generated, lit and meshed on worker threads, and unloaded chunks are written to disk in the background.
• Fewer, bigger draw calls. Terrain sections share one vertex buffer and are drawn with one indirect multi-draw per pass. Mobs and block entities outside the view are skipped, and caves you can’t see into are culled.
• A modern graphics API. Horizon draws through Vulkan, Metal or DirectX 12. In the ThinkPad benchmark notes, Horizon ran on Vulkan while vanilla ran on OpenGL.

And a cautionary example from the same docs: before a fix, Horizon ticked seven times as many mobs, minecarts and dropped items as vanilla at render distance 32, because it ticked everything loaded rather than only what’s inside the simulation distance. Rust didn’t save it from that. That fix was part of one round of performance work (along with background chunk saving and batched drawing), after which a village scene at render distance 16 went from 8 to 1,041 FPS on an RTX 4080. Those before/after numbers compare Horizon with an earlier Horizon, not with Java, but they show how much comes from design.

What the official benchmarks measured

The Benchmarks page ran Horizon and Java Edition 26.3 (as players get it, with the official launcher’s Java options) on three of the project’s machines. Conditions: a fresh creative world on seed 1234, a fixed flight over a village, a forest, an ocean and a mountain, 1280×720 window, VSync off, no frame cap, simulation distance 12, render distance 12, everything else at vanilla defaults. Each figure is a median over runs measured between 22 October and 4 November 2026.

The other two machines: on the Mac mini, Horizon had no hitches at all against 423 a minute for Java Edition; on a gaming desktop, about 70% fewer hitches and 2,224 FPS on average against 1,824. The page lists loading new terrain on the ThinkPad as the case where Java Edition did better.

You may have seen “3× the frame rate” on the Horizon home page. That section is an illustration with a bar you can drag to your own frame rate, not a measurement. Quote the Benchmarks page instead.

Servers tell the same story, with a twist

The project’s bot benchmark ran horizon-server, vanilla 26.3, Paper and Fabric with Lithium on a 4-thread laptop CPU with 1 to 50 bots. Horizon used 0.7 to 1.1 GB against 3.4 to 4.5 GB for the Java servers (each with a 4 GB heap), started in 8 to 9 seconds against 15 to 22, and used the least CPU from 10 players up. But Paper’s average tick was shorter at every player count. Years of Java optimization still count for something. Details in how to host a Horizon server.

The honest summary

Rust gives Horizon predictable frame times and a small memory footprint, and that’s where it shines on modest hardware, as our low-end PC guide shows. Raw speed in any given scene depends just as much on design and on how complete each subsystem is. Horizon checks that it behaves like vanilla with differential harnesses, and its benchmarks publish the losses next to the wins. To see the difference on your own machine, run the built-in benchmark described in how to get more FPS in Horizon.