Pureformance

Pureformance is a client-side performance optimization mod for Minecraft designed to reduce unnecessary CPU, GPU and memory work while preserving vanilla gameplay and visual behavior.

Instead of applying one isolated optimization, Pureformance combines multiple coordinated systems for entity visibility, block entities, rendering, particles, memory, text/UI processing and extreme-load protection.

Its main design rule is simple:

An optimization must remove more work than it adds.

Pureformance is developed around profiling and measured A/B performance testing. Features that introduce measurable regressions are redesigned, disabled or rejected rather than kept simply because they appear theoretically useful.

What Pureformance optimizes

Entity rendering and visibility

Pureformance reduces work spent preparing and rendering entities that cannot meaningfully contribute to the current frame.

Its visibility system combines:

• camera-frustum rejection,
• occlusion testing,
• asynchronous visibility work,
• short-lived visibility caches,
• movement-aware invalidation,
• optimized ray ordering,
• bounded voxel traversal,
• and conservative handling of nearby or gameplay-relevant entities.

Expensive visibility work is budgeted so that the culling system itself does not become a new performance bottleneck.

Block entities

Block entities that are outside the camera frustum can be rejected before more expensive rendering work takes place.

Optional block-entity occlusion can also reject block entities hidden behind solid geometry.

The system is designed to use coarse rejection whenever possible before falling back to more expensive fine-grained visibility checks.

Rendering

Pureformance reduces repeated work in frequently executed rendering paths.

Depending on the active renderer and compatibility environment, this includes optimizations such as:

• render-state reuse,
• reduced temporary allocations,
• redundant framebuffer/state-change avoidance,
• batching improvements,
• map rendering optimizations,
• and specialized fast paths for frequently repeated render work.

Particles

Pureformance uses workload-aware particle optimization rather than permanently reducing particle quality.

During ordinary gameplay, particle behavior is left as close to vanilla as possible.

When particle workloads become unusually expensive, Pureformance can progressively reduce non-essential particle work, collision processing and rendering pressure while prioritizing useful nearby visual information.

Memory

The memory engine reduces repeated allocations and duplicated internal data.

This includes techniques such as:

• canonicalizing equivalent block-state data,
• reusing identical collision information,
• compacting repeated structures,
• reducing temporary render-state allocation,
• and reusing internal objects when doing so is safe.

Reducing allocation pressure also reduces work transferred to Java's garbage collector.

Text and UI

Pureformance includes optimizations for frequently repeated text preparation and rendering.

These include caching and reducing unnecessary lookup, sorting and repeated layout work in hot rendering paths.

Emergency Playability System

Pureformance includes a dedicated Emergency Playability System for situations where the Minecraft client is approaching an extreme workload state.

This is not a permanent low-quality mode.

Under normal conditions, the Emergency System remains inactive.

It continuously observes client tick time, frame time, effective tick rate and accumulated tick debt using moving averages and one-second evaluation windows.

Emergency pressure can rise through three levels.

Typical triggers include sustained conditions such as:

A bad condition must persist across evaluation windows before pressure is increased.

Recovery is also deliberately conservative. The system waits for healthy frame/tick timing and approximately normal tick rate before stepping back down, preventing rapid oscillation between modes.

Most importantly:

Emergency Playability does not cancel world ticks, entity ticks, player ticks, network processing, scheduled ticks or fluid simulation.

Its purpose is to reduce optional client-side work while preserving gameplay correctness.

Entity Catastrophe protection

Pureformance 0.3.5 also contains a render-side circuit breaker specifically designed for pathological entity-density situations.

This targets scenarios such as runaway farms or enormous concentrations of dropped items where the client can otherwise spend an unbounded amount of time preparing entities that cannot reasonably all be useful on screen.

Entity Catastrophe has three density levels:

Dropped-item storms within approximately 48 blocks of the camera use a specialized path with caps of:

• 2,048 at pressure level,
• 1,024 at severe level,
• 256 at catastrophic level.

At the highest level, even a pathological scene containing hundreds of thousands of ordinary entities can therefore avoid attempting to render all of them every frame.

The selection is stable rather than purely random, helping prevent rapid visual flickering.

Gameplay-critical entities bypass this protection, including:

• players,
• projectiles,
• the current player and camera entity,
• passengers and vehicles,
• custom-named entities,
• configured/whitelisted entities,
• and glowing entities.

Entity Catastrophe is render-only.

It does not delete entities and does not skip their world, entity, player, network or fluid ticks.

When entity density falls again, the system automatically steps down after a recovery period.

Dense-entity collision optimization

Pureformance 0.3.5 also optimizes a different bottleneck that becomes important in large item farms: entity collision queries.

Minecraft can repeatedly scan dense entity sections looking for possible collision candidates.

Pureformance maintains a conservative dense-section collision path that avoids scanning entity classes which cannot contribute a valid collision result while preserving Minecraft's normal collision predicates.

This optimization is especially relevant for large numbers of moving dropped items, including water-stream farms.

Measured performance

Pureformance performance claims are based on measured development benchmarks rather than theoretical estimates.

0.3.5 validated farm benchmark

The final 0.3.5 candidate was tested in comparable stationary captures of a real high-density item farm.

The Entity Catastrophe system remained completely inactive during these ordinary farm tests and rejected zero entities, ensuring that the result was not obtained by simply hiding the farm.

Frame-time consistency also improved substantially:

For the >=950 entity band, the accepted 0.3.5 reference measured 24.16 FPS, again with zero Entity Catastrophe render rejection.

These numbers describe this specific controlled workload and are not presented as a universal FPS multiplier.

Collision-index development benchmark

During development of the dense-item collision optimization, a controlled test at approximately 1,000 moving item entities improved the >=950 entity band from approximately:

18.9 FPS → 53.7 FPS

Client tick time improved from approximately:

41.3 ms → 13.2 ms

and integrated-server tick time from approximately:

68.0 ms → 43.8 ms

This experiment also demonstrates how Pureformance development decisions are made.

An accompanying experimental render cap produced additional FPS but hid approximately 85–88% of extracted entities. That render policy was rejected and was not shipped for normal sub-5,000-entity workloads.

The collision optimization was retained because it provided measurable benefit without requiring that visual compromise.

Additional real-world stress snapshots

The gallery includes three screenshots captured from the same high-density farm scene using ModStack Performance Monitor 0.3.0.

They show representative live measurements:

These screenshots are provided as real stress-scene examples, not as the formal controlled release benchmark.

The captures have different recording durations and the dynamic farm contained different loaded-entity counts during each snapshot, so Pureformance does not use these three screenshots to claim a fixed performance multiplier.

The controlled 0.3.5 farm results above are the benchmark used for release decisions.

Benchmark methodology

Pureformance uses ModStack Performance Monitor to collect repeatable client performance measurements.

For controlled A/B comparisons the development protocol requires:

• the same computer,
• the same Minecraft version and Java version,
• the same loader and mod configuration apart from the variable being tested,
• the same world and observation point or recorded camera route,
• identical render and simulation distances,
• identical graphics settings, resource packs, shaders, window state and FPS cap,
• a 30-second warm-up period,
• multiple valid measured passes,
• and retention of the original reports for comparison.

Measured metrics include:

• average FPS,
• 1% and 0.1% lows,
• average/P95/P99 frametime,
• client tick time,
• non-tick frame work,
• integrated-server tick time where available,
• loaded/extracted/rendered entities,
• particle workload,
• heap usage,
• allocation rate,
• garbage-collection activity,
• and Pureformance internal counters.

Correctness is a hard gate.

A candidate optimization is rejected regardless of its FPS result if it introduces crashes, incorrect visibility, altered entity movement, broken particle rendering, fluid problems or other gameplay differences attributable to the optimization.

Adaptive rather than aggressive

Pureformance does not simply apply the strongest available shortcut.

Its optimization systems make extensive use of:

• processing budgets,
• short-lived caches,
• distance limits,
• movement invalidation,
• stable sampling,
• workload pressure levels,
• conservative bypass rules,
• and hysteresis.

This is intentional.

Reducing work is useful only when the optimization itself costs less than the work being removed and does not compromise gameplay correctness.

Client-side and world-safe

Pureformance operates on client-side processing and rendering.

It does not add:

• blocks,
• items,
• entities,
• world generation,
• progression,
• or gameplay mechanics.

It does not require world conversion and does not modify saved-world data.

Removing Pureformance does not require converting the world back to another format.

Compatibility

Pureformance is designed to coexist with modern Minecraft performance stacks.

Sodium

Sodium is a recommended complementary mod.

Sodium provides its own highly optimized rendering engine, while Pureformance focuses on additional entity, block-entity, workload, memory and adaptive optimization systems.

Pureformance is developed and benchmarked in Sodium environments as well as without Sodium.

Item Frame Cache

Item Frame Cache is a companion optimization mod for scenes containing large numbers of item frames.

It caches repeated rendering work for item frames displaying both maps and normal objects and is designed to complement Pureformance without duplicating its main optimization systems.

Configuration

Pureformance creates a pureformance.json configuration file.

The defaults are intended for normal users, while advanced users and modpack developers can individually configure systems such as:

• entity and block-entity culling,
• occlusion distance and ray limits,
• visibility-cache sizes and lifetimes,
• per-frame voxel budgets,
• render-state reuse,
• memory optimization,
• particle workload controls,
• Emergency Playability,
• Entity Catastrophe protection,
• and diagnostic logging.

The safety systems are designed to recover automatically when workload returns to normal.

Development and validation

Pureformance is actively developed using a profiling-first workflow.

Development normally follows this sequence:

1. identify a measurable bottleneck;
2. profile the affected code path;
3. design a bounded optimization;
4. validate gameplay correctness;
5. perform controlled A/B measurements;
6. inspect frame time, tick time, allocations and relevant subsystem counters;
7. reject, redesign or retain the optimization based on measured results;
8. compile and audit the final release artifact.

Pureformance 0.3.5 passed its Fabric runtime validation and final build/JAR audit.

The Fabric, Quilt and NeoForge release artifacts also pass the project's structural compilation and JAR validation process.

AI-assisted development

Pureformance openly uses AI-assisted engineering tools.

AI assists with implementation, code exploration, debugging, technical analysis, documentation and development iteration.

It is not used as an autonomous release process.

Human developers remain responsible for:

• architecture,
• algorithm and optimization strategy,
• profiling methodology,
• benchmark design,
• feature selection,
• interpretation of performance results,
• compatibility decisions,
• correctness criteria,
• and release decisions.

AI-assisted implementations are manually inspected, integrated, modified where necessary, debugged and validated by programmers before release.

The benchmark history above also illustrates this process: implementations that produce attractive FPS numbers but fail visual or gameplay requirements are rejected rather than shipped.

Pureformance therefore uses an AI-assisted, human-directed and measurement-driven engineering process, with human responsibility for the released software.

Current release

Pureformance 0.3.5

Minecraft 26.2
Client-side performance optimization
Available for Fabric, Quilt and NeoForge

Performance will always vary with hardware, world complexity, entity density, graphics settings and installed mods.

Pureformance does not promise a universal FPS multiplier.

It provides measurable optimization systems designed to reduce unnecessary work, remain bounded under normal workloads, and protect client playability when workloads become extreme.