Fast Loading — Preview 1

The beginning of Fast Loading

This is the first preview of Fast Loading, a new optimization mod focused specifically on reducing the time spent waiting for Minecraft.

Adaptive Optimization is still in development and has not been abandoned or replaced.

AO continues moving toward its complete version.

However, its core architecture is now mature enough that development can begin expanding into the next major Adaptive Mods project:

Fast Loading

The goal is simple to describe, although much harder to achieve:

start Minecraft faster
↓
reach the menu faster
↓
load worlds and servers faster
↓
reduce repeated loading work
↓
learn which loading strategies actually help each environment

This first preview establishes the foundation for that system.

Why Fast Loading is starting now

Adaptive Optimization has reached a point where many of its fundamental ideas are already established:

• exact environment identity;

• adaptive experimentation;

• evidence-based decisions;

• promotion and rollback;

• persistent learning;

• environment-specific behavior;

• bounded autonomous optimization.

AO itself still has remaining development and validation work.

But it is no longer necessary to wait for every final AO system before beginning another Adaptive Mod.

Fast Loading can now begin developing independently while reusing several of the architectural lessons learned while building AO.

This also has an important practical benefit.

Testing AO currently requires many repeated:

Minecraft launches
↓
modpack startups
↓
world joins
↓
server joins
↓
restarts

Large modpacks can make those cycles extremely slow.

Fast Loading is therefore not only another optimization project.

It can eventually make development and testing of AO itself much faster.

Fast Loading already has its first real startup optimization path

This preview introduces an early loading optimization system that can begin working near Minecraft's startup boundary.

Fast Loading can perform bounded early warm-up work before normal loading has progressed very far.

Instead of blindly reading entire mod files, the system works within strict:

• time budgets;

• byte limits;

• JAR limits;

• per-operation limits.

Its purpose is to prepare useful filesystem data before later loading stages need it.

This initial implementation focuses heavily on mod JAR access.

Persistent JAR indexing begins

One of the first important Fast Loading systems is a:

persistent JAR index

Fast Loading can retain information about mod JAR structures between launches.

The index can remember useful byte locations such as:

• ZIP central-directory regions;

• selected frequently useful entries;

• metadata-related areas.

This means later launches do not necessarily need to rediscover the same JAR structure from zero every time.

The index validates local file information before reuse.

If an entry is stale, missing or invalid, Fast Loading can rebuild it or fall back safely.

Most importantly:

the index is not authoritative over Forge or Minecraft mod discovery.

It does not decide:

• which mods exist;

• which classes Forge loads;

• which resources exist;

• what a mod is allowed to execute.

It is used only to improve how Fast Loading prepares data that the normal loader may need later.

Early JAR warm-up is now bounded and selective

Fast Loading does not simply read every installed mod into memory.

The early warm-up system can prioritize a bounded number of JARs and useful JAR regions.

It can prepare areas associated with information such as:

• META-INF/mods.toml;

• manifests;

• pack.mcmeta;

• mixin-related metadata;

• refmaps;

• access wideners;

• ZIP central-directory data.

The system remains constrained by startup budgets.

If its deadline or byte budget is reached:

Fast Loading stops instead of continuing unlimited background work.

This is an important foundation for keeping the optimization itself from becoming another source of loading delay.

Loading is beginning to be divided into measurable phases

Fast Loading now has phase-level telemetry rather than treating startup as one giant number.

The current architecture can distinguish loading regions including:

• total startup;

• early warm-up;

• main entry to mod runtime;

• mod runtime to menu;

• menu background warm-up;

• resource-reload background warm-up;

• world/server entry;

• join background warm-up.

This is important because:

"Minecraft took 40 seconds to open" is not enough information to optimize it intelligently.

Fast Loading needs to know where those 40 seconds were spent.

Future optimizations can then target the phase that actually contains the bottleneck.

Fast Loading measures more than startup time

The initial learning system already records multiple costs.

Evidence can include:

• startup duration;

• process CPU time;

• peak heap growth;

• garbage-collection activity;

• amount of data warmed;

• work performed by Fast Loading itself.

This allows future decisions to consider tradeoffs.

For example, an optimization that saves a small amount of startup time but dramatically increases memory, IO or CPU pressure should not automatically be considered better.

The long-term goal is:

faster loading without simply moving the cost somewhere else.

Adaptive loading profiles begin

Fast Loading already has its first bounded adaptive profiles.

Current profiles include:

• CONSERVATIVE

• BALANCED

• AGGRESSIVE

These profiles can adjust things such as:

• warm-up budget;

• maximum warmed bytes;

• number of JARs considered;

• amount of selected JAR content prepared.

The profile is not intended to become a permanent universal preset chosen blindly for every modpack.

Fast Loading can collect evidence and learn which profile performs better for the current environment.

Experiment, promotion and rollback foundations are already present

Fast Loading does not need to assume that a more aggressive strategy is automatically faster.

It can establish a local baseline, test another profile and compare repeated observations.

A candidate can then be:

tested
↓
compared
↓
promoted

or:

tested
↓
regression detected
↓
rolled back

The current comparison already considers several dimensions rather than startup time alone.

Hard regressions in areas such as:

• startup time;

• memory;

• IO;

• garbage collection;

• CPU

can prevent an experimental profile from being promoted.

This is only the beginning of Fast Loading's future adaptive system, but the important rule already exists:

measure before permanently keeping an optimization.

Incomplete launches can be detected

Startup experiments also need to survive failure cases.

If Minecraft begins an experimental launch but never reaches the expected completion boundary, Fast Loading can retain evidence that the launch was incomplete.

Repeated incomplete experimental launches can therefore contribute to rollback instead of allowing a broken candidate to remain indefinitely.

This starts building crash/restart awareness into Fast Loading from the beginning.

Fast Loading knows which environment produced its evidence

Like Adaptive Optimization, Fast Loading is beginning with stronger environment identity rather than relying only on the instance folder.

The current model can distinguish concepts such as:

• installation identity;

• pack family identity;

• exact pack identity;

• session identity;

• runtime side;

• Minecraft version;

• loader/version;

• hardware/JVM identity.

The directory path is not treated as the authoritative identity of the modpack.

This matters because Minecraft instances can be:

• renamed;

• copied;

• moved;

• restored;

• updated.

Exact packs and related packs are not treated as the same thing

Fast Loading can distinguish between:

the exact current modpack

and:

the broader pack family

An updated version of a modpack may still belong to the same logical family while having a different exact composition.

This opens the door for future knowledge transfer.

Previous evidence may help Fast Loading decide what should be tested first in a related pack.

But:

evidence from another environment cannot promote a loading strategy by itself.

The current installation must still validate the strategy locally.

Menu and world-entry background preparation has begun

Not all useful loading work needs to happen during the initial startup.

Fast Loading can also perform small, budgeted work after reaching later stages.

This first preview includes foundations for background preparation around:

• the main menu;

• world/server entry;

• resource reloads;

• join-related loading.

The system can also prepare small pieces of commonly relevant local data, including selected world information and bounded region-file headers.

This work is distributed through small runtime budgets instead of attempting to perform everything at once.

Safe Mode exists from the beginning

Fast Loading already includes a more conservative operating mode.

Safe Mode reduces several optimization budgets and disables or limits some more aggressive preparation.

This gives the project an escape path for environments where aggressive warm-up behavior causes problems.

As development continues, safety will remain part of the architecture rather than something added only after optimization work is complete.

This is not the finished Fast Loading architecture

This first preview should not be interpreted as:

"Fast Loading is complete."

It is the opposite.

This release establishes the first serious foundation from which much more aggressive loading optimization can now be developed.

The current systems are primarily building the ability to:

identify the environment
↓
measure loading precisely
↓
perform bounded preparation
↓
remember useful JAR information
↓
experiment with loading profiles
↓
compare results
↓
promote or rollback

Now that this foundation exists, future previews can begin attacking larger loading bottlenecks.

Where Fast Loading is going

The long-term objective goes far beyond warming a few files.

Future development can progressively investigate optimization opportunities across:

• Minecraft startup;

• Forge initialization;

• mod discovery;

• mod loading;

• classloading;

• resource discovery;

• resource reloads;

• world loading;

• server joining;

• dimension transitions;

• shutdown and restart cycles;

• repeated loading work;

• filesystem and JAR access;

• dependency-aware preparation;

• reusable loading knowledge between environments.

The goal is eventually to make even extremely large modpacks feel dramatically less expensive to start and enter.

The target is especially important for huge modpacks

Fast Loading is being developed with increasingly large environments in mind.

A small modpack may already start reasonably quickly.

The real challenge is environments with:

hundreds of mods

and eventually:

1,000+ mods

where every unnecessary repeated operation becomes much more visible.

Fast Loading will therefore be developed around the idea that optimizations must continue making sense as the environment grows.

Adaptive Optimization development continues

Starting Fast Loading does not mean Adaptive Optimization development has ended.

AO still has remaining work before its complete version.

Development will continue where necessary to finish:

• final runtime integration;

• autonomous optimization paths;

• safety guarantees;

• validation;

• diagnostics;

• real-world testing;

• remaining edge cases.

The difference is that the project has now reached a point where AO no longer needs to block the beginning of Fast Loading.

AO can continue moving toward completion while Fast Loading begins building its own foundation.

What this preview represents

This is the first step toward another major Adaptive Mod.

Adaptive Optimization focuses on learning how to make the running game more efficient.

Fast Loading begins with a different question:

how much of the waiting before you can actually play can be eliminated?

The first foundation is now in place:

exact environment identity
↓
loading telemetry
↓
persistent JAR knowledge
↓
bounded warm-up
↓
adaptive profiles
↓
experimentation
↓
promotion / rollback

This is only Preview 1.

The aggressive loading optimizations come next.

Fast Loading development has officially begun.