JEIOptimizer

Builds JEI's ingredient filter index in parallel — cuts server join time by up to 17 seconds on large modpacks.

The story

I was playing on a private AllTheMods server with friends. Every disconnect, every restart, every "let me grab a snack" meant 40 seconds of staring at "Joining world..." while everyone else was already mining.

Got tired of it. Spent a weekend with JEI's source code open instead of playing the game. This mod is what came out.

What it does

When you connect to a modded server, JEI rebuilds its entire item search index from scratch — because the server may ship custom recipes. On a 250-mod pack with ~50,000 items, this takes 12+ seconds on the main thread. Your client just sits frozen.

JEIOptimizer parallelizes JEI's IngredientFilter build across worker threads. Each search prefix (item name, mod ID, tag, tooltip, ...) gets its own thread, running on independent data structures — no contention, no races, no risks.

Real-world measurements

Tested on a 250+ mod pack (AE2, Mekanism, Create, Cobblemon, Apotheosis, AllTheCompressed, ...). Ryzen 5600X · 10 worker threads · NVMe · 8 GB RAM allocated · remote server (Hetzner DC).

Combined with the bonus tweak below (see Free 8 more seconds), you can drop server connect from 40 s → ~23 s consistently.

How it works (technical)

JEI's IngredientFilter builds a search index where each "prefix" (name, modId, tag, tooltip, ...) has its own GeneralizedSuffixTree. Independent structures → safe to build in parallel.

Vanilla JEI:

for each ingredient (50,000):
    for each prefix (7-10):
        compute tokens → insert into suffix tree

One thread = ~12 seconds.

JEIOptimizer:

parallelStream over prefixes:
    for each ingredient:
        compute tokens → insert into own suffix tree

6-10 cores doing 7-10 prefixes simultaneously = ~0.8 seconds.

Filter modes (in config)

• OFF — vanilla JEI behavior
• BATCH — small cache-friendly improvement, single-threaded
• PARALLEL_PREFIX — parallel per-prefix build (safe)
• PARALLEL_FULL — also parallelizes tokenization within prefix (default, fastest)

Free 8 more seconds (manual JEI tweak)

In config/jei/jei-client.ini, change:

tooltipSearchMode = DISABLED

JEI indexes the tooltip text of every item on every connect. Some mods do heavy I/O in tooltip rendering — eating ~8 of those original 12 seconds for nothing. Players almost always search by name, not tooltip text.

If players want tooltip search via #prefix, use REQUIRE_PREFIX instead.

Configuration

config/jeioptimizer-client.toml (auto-generated):

[filter]
    mode = "PARALLEL_FULL"   # Default. Safe, fastest.
    async = false            # Experimental: build in background
    log_timing = true        # Log timings for verification

worker_count = 0             # 0 = auto (cores - 2)

[plugins]
    parallel_phases = []                # Experimental — see below
    parallel_creative_tabs = false      # Experimental — see below

Safe defaults out of the box. Drop the jar in, you get the win. No config touching required.

Compatibility

• Minecraft: 1.21.1
• Mod loader: NeoForge 21.x
• JEI: 19.x (1.21.1 builds)
• Side: Client-only — server installation not needed

What this WON'T speed up

Being honest about scope:

• ❌ Game launch (mod construction, model baking, resource pack reload)
• ❌ Server data sync (recipes, tags, registries) — network and mod serialization bound
• ❌ Per-mod runtime data regen — Create generates 2,124 recipes every connect, Cobblemon resyncs all fossils/marks/berries, Apotheosis reloads all affixes. These are mod-design choices.

JEIOptimizer removes JEI from the bottleneck. It's no longer the long pole — other mods still do their thing.

Experimental features (default OFF)

Tested but found to break things on real mod packs. Available as opt-in for those with carefully chosen mod sets:

• plugins.parallel_phases — Parallel plugin recipe registration. Many JEI plugins (Theurgy, Ars Nouveau, Compact Machines) are not thread-safe and crash.
• plugins.parallel_creative_tabs — Parallel creative tab build. Many mods cache tab state non-thread-safely; in our test 22% of JEI items were lost.
• filter.async — Builds filter in background; player enters world sooner. If they open JEI in the first 2 seconds, they see an empty grid until ready.

Leave these off unless you know what you're doing.

FAQ

Q: Will this break JEI search? Default mode (PARALLEL_FULL) changes how the index is built, not what. Same items, same recipes, same search results.

Q: I have a smaller modpack. Will I see less benefit? Yes. Below ~10,000 items the gain is marginal. Designed for 30k+ item packs.

Q: Why not submit a PR to JEI? Maybe later. Mezz (JEI's author) historically prefers conservative changes — parallelism in core code may not be welcomed. This mod exists so you don't have to wait for upstream.

Q: Server-side install needed? No. Pure client-side mixin. Putting it in mods/ on a server is a no-op.

Q: Does it work with EMI / REI? No, this targets JEI specifically. EMI has its own architecture (and is already fast).

Credits

Tested on a custom 250+ modpack and AllTheMods10, AllTheMons.

Thanks to Mezz for keeping JEI's source open and readable enough to optimize from the outside.

JEIOptimizer

Builds JEI's ingredient filter index in parallel — cuts server join time by up to 17 seconds on large modpacks.

The story

I was playing on a private AllTheMods server with friends. Every disconnect, every restart, every "let me grab a snack" meant 40 seconds of staring at "Joining world…" while everyone else was already mining.

Got tired of it. Spent a weekend with JEI's source code open instead of playing the game. This mod is what came out.

What it does

When you connect to a modded server, JEI rebuilds its entire item search index from scratch — because the server may ship custom recipes. On a 250-mod pack with ~50,000 items, this takes 12+ seconds on the main thread. Your client just sits frozen.

JEIOptimizer parallelizes JEI's IngredientFilter build across worker threads. Each search prefix (item name, mod ID, tag, tooltip, …) gets its own thread, running on independent data structures — no contention, no races, no risks.

Real-world measurements

Tested on a 250+ mod pack (AE2, Mekanism, Create, Cobblemon, Apotheosis, AllTheCompressed, …). Ryzen 5600X · 10 worker threads · NVMe · 8 GB RAM allocated · remote server (Hetzner DC).

Combined with the bonus tweak below (see Free 8 more seconds), you can drop server connect from 40 s → ~23 s consistently.

How it works (technical)

JEI's IngredientFilter builds a search index where each "prefix" (name, modId, tag, tooltip, …) has its own GeneralizedSuffixTree. Independent structures → safe to build in parallel.

Vanilla JEI:

for each ingredient (50,000):
    for each prefix (7-10):
        compute tokens → insert into suffix tree

One thread = ~12 seconds.

JEIOptimizer:

parallelStream over prefixes:
    for each ingredient:
        compute tokens → insert into own suffix tree

6-10 cores doing 7-10 prefixes simultaneously = ~0.8 seconds.

Filter modes (in config)

• OFF — vanilla JEI behavior
• BATCH — small cache-friendly improvement, single-threaded
• PARALLEL_PREFIX — parallel per-prefix build (safe)
• PARALLEL_FULL — also parallelizes tokenization within prefix (default, fastest)

Free 8 more seconds (manual JEI tweak)

In config/jei/jei-client.ini, change:

tooltipSearchMode = DISABLED

JEI indexes the tooltip text of every item on every connect. Some mods do heavy I/O in tooltip rendering — eating ~8 of those original 12 seconds for nothing. Players almost always search by name, not tooltip text.

If players want tooltip search via #prefix, use REQUIRE_PREFIX instead.

Configuration

config/jeioptimizer-client.toml (auto-generated):

[filter]
    mode = "PARALLEL_FULL"   # Default. Safe, fastest.
    async = false            # Experimental: build in background
    log_timing = true        # Log timings for verification

worker_count = 0 # 0 = auto (cores - 2)

[plugins] parallel_phases = [] # Experimental — see below parallel_creative_tabs = false # Experimental — see below

Safe defaults out of the box. Drop the jar in, you get the win. No config touching required.

Compatibility

• Minecraft: 1.21.1
• Mod loader: NeoForge 21.x
• JEI: 19.x (1.21.1 builds)
• Side: Client-only — server installation not needed

What this WON'T speed up

Being honest about scope:

• ❌ Game launch (mod construction, model baking, resource pack reload)
• ❌ Server data sync (recipes, tags, registries) — network and mod serialization bound
• ❌ Per-mod runtime data regen — Create generates 2,124 recipes every connect, Cobblemon resyncs all fossils/marks/berries, Apotheosis reloads all affixes. These are mod-design choices.

JEIOptimizer removes JEI from the bottleneck. It's no longer the long pole — other mods still do their thing.

Experimental features (default OFF)

Tested but found to break things on real mod packs. Available as opt-in for those with carefully chosen mod sets:

• plugins.parallel_phases — Parallel plugin recipe registration. Many JEI plugins (Theurgy, Ars Nouveau, Compact Machines) are not thread-safe and crash.
• plugins.parallel_creative_tabs — Parallel creative tab build. Many mods cache tab state non-thread-safely; in our test 22% of JEI items were lost.
• filter.async — Builds filter in background; player enters world sooner. If they open JEI in the first 2 seconds, they see an empty grid until ready.

Leave these off unless you know what you're doing.

FAQ

Q: Will this break JEI search? Default mode (PARALLEL_FULL) changes how the index is built, not what. Same items, same recipes, same search results.

Q: I have a smaller modpack. Will I see less benefit? Yes. Below ~10,000 items the gain is marginal. Designed for 30k+ item packs.

Q: Why not submit a PR to JEI? Maybe later. Mezz (JEI's author) historically prefers conservative changes — parallelism in core code may not be welcomed. This mod exists so you don't have to wait for upstream.

Q: Server-side install needed? No. Pure client-side mixin. Putting it in mods/ on a server is a no-op.

Q: Does it work with EMI / REI? No, this targets JEI specifically. EMI has its own architecture (and is already fast).

Credits

Tested on a custom 250+ modpack and AllTheMods10, AllTheMons.

Thanks to Mezz for keeping JEI's source open and readable enough to optimize from the outside.