Fast Loading

Fast Loading is a Minecraft optimization mod focused on reducing the time you spend waiting.

The goal is not only faster startup.

Fast Loading is being designed to optimize the entire loading cycle:

Launch Minecraft → Main Menu → World/Server → Dimensions → Resource Packs/Shaders → Exit World → Main Menu

while learning from previous runs and avoiding unnecessary repeated work whenever it can be reused safely.

Initial Preview

Fast Loading is currently in its first preview stage.

The foundation of the mod is already being developed, but many of the deeper loading optimizations planned for Fast Loading will be introduced progressively in future versions.

Performance improvements can therefore vary depending on:

• your modpack;

• hardware;

• storage;

• Minecraft configuration;

• and which loading bottlenecks are currently covered.

Future previews will continue expanding the number of loading stages Fast Loading can optimize.

What Fast Loading aims to optimize

Fast Loading is being developed to reduce waiting across the complete Minecraft loading cycle, including:

• Minecraft startup

• Forge/mod loading

• Mod discovery

• JAR and metadata processing

• Classloading

• Mixins and transformations

• Resource loading

• Resource-pack reloads

• Shader loading

• World entry

• Multiplayer server joining

• Dimension transitions

• World saving and exit

• Repeated launches of unchanged modpacks

The objective is especially important for large modpacks where the same files, mods and resources may otherwise require significant repeated work every time Minecraft starts.

Adaptive loading optimization

Fast Loading is not designed around one fixed optimization strategy for every computer.

Different systems can have completely different loading bottlenecks.

For example, an HDD, SATA SSD and NVMe SSD may benefit from different loading strategies.

Fast Loading is being built to observe factors such as:

• loading time;

• CPU usage;

• memory usage;

• garbage collection;

• disk I/O;

• individual loading phases;

• failures and crashes.

Using this information, Fast Loading can progressively determine which loading approaches actually help the current environment.

The long-term adaptive cycle is:

observe
↓
find bottleneck
↓
test optimization
↓
compare
↓
keep or rollback
↓
remember

This means Fast Loading does not need to assume that a theoretically faster optimization is automatically better.

Stop repeating work that has not changed

A major focus of Fast Loading is eliminating unnecessary repeated work.

Minecraft modpacks can contain hundreds or even thousands of JARs, configuration files, metadata files, resources and transformations.

Much of this information may remain identical between launches.

Fast Loading is being developed around systems such as:

• persistent JAR indexing;

• metadata and parsing caches;

• incremental mod discovery;

• dependency-aware invalidation;

• safe transformation reuse;

• persistent resource indexes;

• reusable world metadata;

• environment-specific loading knowledge.

The important principle is:

unchanged work should not need to be rediscovered forever.

At the same time, cached information must only be reused when Fast Loading can verify that the relevant environment still matches.

If something changes, only the affected information should eventually need to be recalculated whenever possible.

Safety-first caching

Fast Loading is intended to be one of the safest optimization mods in the Adaptive Mods ecosystem.

Its job is primarily to optimize how expensive loading work is, not to change what Minecraft or another mod is supposed to do.

Fast Loading is being designed around a simple rule:

if cached or optimized work cannot be proven safe to reuse, perform the normal work instead.

The mod should never need to gain speed by intentionally:

• skipping required mod initialization;

• changing gameplay behavior;

• altering recipes or mechanics;

• modifying player settings;

• returning known-stale cached data;

• bypassing required save operations;

• pretending that loading completed before required work actually finished.

A cache miss is acceptable.

Recalculating something is acceptable.

Using incorrect data just because it is faster is not.

This conservative approach is especially important because Fast Loading operates around initialization, resources, worlds and other areas where incorrect reuse could otherwise cause difficult compatibility problems.

Persistent and incremental caching

Fast Loading does not aim to create one giant cache and blindly reuse it forever.

Cached information should be tied to the things that make it valid.

Depending on the system, this may include information such as:

• file fingerprints;

• mod versions;

• Minecraft version;

• loader version;

• relevant configuration;

• transformation inputs;

• environment identity;

• hardware characteristics.

If the required inputs change:

cache hit → becomes cache miss

and the affected information can be rebuilt normally.

The long-term goal is increasingly precise invalidation:

one thing changed
↓
invalidate what depends on it
↓
preserve everything else that is still valid

instead of:

one thing changed → delete everything.

Designed for huge modpacks

Fast Loading is being developed with environments ranging from relatively small modpacks to extremely large installations with hundreds or potentially:

1,000+ mods

Large modpacks are particularly important because small repeated costs can accumulate into minutes of loading time.

The architecture therefore also has to make sure Fast Loading does not become its own bottleneck.

Its:

• cache size;

• memory consumption;

• disk usage;

• background work;

• indexes;

• loading history

must remain bounded and useful as modpacks grow.

Saving 30 seconds of loading would not be a good optimization if Fast Loading needed gigabytes of unnecessary cache or excessive memory to achieve it.

Different hardware needs different strategies

Fast Loading is also intended to adapt its behavior to the machine running it.

A low-end computer with:

• limited RAM;

• few CPU threads;

• an HDD or SATA SSD

should not necessarily use the same loading strategy as a system with:

• many CPU cores;

• large amounts of memory;

• a fast NVMe drive.

For example, aggressively parallelizing disk reads may help one computer while making another dramatically slower.

Fast Loading's long-term goal is therefore not:

maximum parallelism

but:

the most effective loading strategy for the current machine and modpack.

World loading

Fast Loading is not limited to launching Minecraft.

World entry is another major target.

Future systems can progressively optimize work related to:

• world discovery;

• level.dat;

• datapacks;

• registries;

• integrated-server startup;

• persistent mod data;

• resource synchronization;

• chunk-related preparation.

Safe reusable world information may also be prepared before the player enters a commonly used world.

The goal is to reduce the amount of work that has to happen after pressing:

Play Selected World

without compromising save correctness.

Multiplayer

Fast Loading will also target the local work involved when connecting to multiplayer servers.

Potential optimization areas include:

• known-server preparation;

• resource packs;

• local registry processing;

• mod handshakes;

• repeated resource work;

• reusable local server information.

Fast Loading cannot eliminate physical network latency or make a remote server itself process things faster.

But it can attempt to reduce unnecessary waiting caused by work performed on the player's own computer.

Resource packs and shaders

Resource reloads can also become extremely expensive in heavily modded environments.

Fast Loading is intended to eventually optimize repeated processing associated with:

• resource discovery;

• metadata;

• models;

• JSON;

• atlas inputs;

• texture/resource indexes;

• shader preprocessing;

• shader compilation preparation.

Shader reuse must also account for relevant compatibility factors such as GPU, drivers, shader pack versions and rendering mods.

Fast Loading should never blindly assume that GPU-related state remains compatible between environments.

Dimension transitions

Fast Loading is also planned to learn repeated dimension transitions.

For example:

Overworld → Nether

may require different preparation than:

Overworld → a large modded dimension

If Fast Loading can safely predict likely work before the transition happens, some preparation may eventually happen in advance under strict resource budgets.

The amount of preparation can depend on the machine.

A low-memory computer should be able to prepare much less than a system with significant unused resources.

Faster world exit

Loading optimization also applies when leaving the game.

Fast Loading is intended to investigate the work performed during:

• world saving;

• serialization;

• compression;

• disk writes;

• integrated-server shutdown;

• resource cleanup.

Where it is safe, some work may be prepared incrementally during gameplay instead of leaving everything until the player presses:

Save and Quit to Title

But durability remains more important than appearing fast.

Fast Loading should never claim that a world is safely closed before the required save operations are actually complete.

Learning between modpacks

Some loading knowledge may be useful across different environments.

For example, Fast Loading may learn that a certain I/O strategy generally performs better on a particular hardware profile.

That knowledge can later influence which strategies are tested first elsewhere.

However:

knowledge transferred from another modpack is only a prior, not automatic proof.

A strategy that worked in Pack A should still be validated before becoming authoritative for Pack B.

This allows Fast Loading to learn from previous experience without assuming every modpack behaves identically.

Relationship with Adaptive Optimization

Adaptive Optimization is still actively being developed.

Fast Loading is beginning now because AO has already established many of the architectural ideas needed for adaptive optimization systems.

Those lessons include:

• environment identity;

• provenance;

• adaptive learning;

• multidimensional evaluation;

• rollback;

• bounded working sets;

• self-overhead control;

• knowledge transfer;

• semantic preservation.

Fast Loading can implement smaller and more specialized versions of those ideas instead of rediscovering them from zero.

Fast Loading is designed to work independently.

Adaptive Optimization is not required.

In the future, Adaptive Optimization, Fast Loading and other Adaptive Mods may exchange useful evidence and knowledge while remaining independent optimizers.

Fast Loading can also accelerate development itself

There is another important reason Fast Loading is starting now.

Developing and testing optimization mods requires repeatedly:

build
↓
launch Minecraft
↓
load a modpack
↓
enter a world
↓
test
↓
restart

With large modpacks, a significant part of development time can simply be spent waiting.

As Fast Loading improves, it can reduce that iteration time.

That means it can eventually help accelerate testing for:

• Adaptive Optimization;

• Fast Loading itself;

• future Adaptive Mods.

Fast Loading is therefore both a player-facing optimization project and potentially an important part of the development workflow for the entire ecosystem.

Current status

This is the initial preview of Fast Loading.

The foundation is being established first:

environment identity
↓
loading telemetry
↓
persistent loading knowledge
↓
bounded caching
↓
adaptive strategies
↓
experimentation
↓
promotion / rollback

From there, development will progressively move deeper into:

mod discovery
↓
metadata parsing
↓
classloading
↓
ASM / Mixins
↓
resources
↓
worlds
↓
servers
↓
dimensions
↓
shaders
↓
saving and exit

The objective is not to fake instant loading.

The objective is to remove as much real unnecessary loading work as safely possible.

Discord

Development discussion, testing, suggestions and bug reports are welcome:

https://discord.gg/9WZDxVY4m

Performance reports are especially useful.

If possible, include whether Fast Loading:

• improved loading;

• made no noticeable difference;

• caused a regression;

• behaved differently after multiple launches.

Feedback from both low-end systems and extremely large modpacks is particularly valuable.

Fast Loading has only just begun.

Its long-term goal is simple:

make heavily modded Minecraft spend as little time waiting as safely possible.