JEI

JEI

Minecraft 1.20.1 / Forge: this page documents that build and its measurements. For the separate 170-control Minecraft 1.21.1 port, see Minecraft 1.21.1 NeoForge.

Seven controls for JEI 15.59.0.212 (mod id jei), all client-side: each ingredient keeps its own display stack, the item registry is looked up once instead of for every recipe slot, part of the search index is built in the background, and the ingredient list is sorted by keys worked out in advance. Since 1.0.33, brewing recipes are found by their ID while JEI builds its recipe list, tooltip search words are read without regex matching, and JEI's hidden anvil and grindstone menus skip synchronization scans nobody observes. Every switch checks the code it would change against the tested build; another build is left untouched with one WARN line (see How the patches are applied).

Key	Target	Side	Since	Kind
jei_baked_index_background_grams	JEI 15.59.0.212	CLIENT	1.0.30	opt
jei_brewing_lookup	JEI 15.59.0.212	CLIENT	1.0.31	opt
jei_hidden_menu_sync	JEI 15.59.0.212 / Minecraft 1.20.1	CLIENT	1.0.31	opt
jei_server_item_registry	JEI 15.59.0.212 + Forge 47.4.16	CLIENT	1.0.26	opt
jei_sort_index_keys	JEI 15.59.0.212	CLIENT	1.0.30	opt
jei_tooltip_words	JEI 15.59.0.212	CLIENT	1.0.31	opt
jei_typed_stack_cache	JEI 15.59.0.212	CLIENT	1.0.26	opt

---

jei_server_item_registry

Since: 1.0.26 · Target: JEI 15.59.0.212 + Forge 47.4.16 · Side: CLIENT · Kind: opt

Mixins: ServerItemRegistryMixin

For every stack of every recipe slot it indexes, JEI checks that the server knows the item, and built a new wrapper around Forge's item registry for each check (a map lookup and an allocation). The wrapper of the active item registry is now kept once that registry exists. Forge never replaces or removes that registry object (a sync with a server changes its contents in place), so the check itself is unchanged.

Measured: offline with JEI's own platform code and Forge's registry manager, every vanilla item plus unregistered items, before and after removing items from the registry: identical answers; 18.6 -> 12.3 ns per check. 1.1% of the main thread while JEI starts before.

---

jei_typed_stack_cache

Since: 1.0.26 · Target: JEI 15.59.0.212 · Side: CLIENT · Kind: opt

Mixins: TypedStackCacheMixin

JEI kept the ItemStack of every listed or indexed ingredient in one shared cache that forgets an entry one second after its last use. While JEI starts nearly every lookup is for a new ingredient, and every insert walked the cache's expiry list. Each ingredient now keeps its own stack under the same one-second rule, with the cache's behaviour for several threads asking at once and for errors: the same stack object within a second of the last use, a new one after it.

Measured: offline against the cache library itself with a test clock, 930 000 lookups including every error case and two threads loading at once: identical results; 830 -> 130 ns per lookup while JEI indexes recipes, 100 -> 38 ns for repeated lookups. 4.8% of the main thread while JEI starts (about 2.4 s) before.

---

jei_baked_index_background_grams

Since: 1.0.30 · Target: JEI 15.59.0.212 · Side: CLIENT · Kind: opt

Mixins: BakedIndexBuilderMixin, BakedIndexAccessor

JEI search index grams built in the background. When you join a world, JEI builds its search index on the render thread ("Building ingredient filter", 2.6-4.3 s here). For every name and tooltip word it collects, its index builder later works out every 1-, 2- and 3-letter piece of the word and lists which words contain it, all in one go at the end (about a fifth of that time). Now the words are also handed, as they are collected, to one background thread that works out the same lists while the render thread is still asking the mods for tooltips; at the end JEI builds its index with those lists. The background thread only reads the finished words, never mod code. The lists hold the same words in the same order and the index is laid out exactly as before, so search results are identical. Large indexes only (16,384+ words).

Idea: JEIOptimizer and Just Enough Threads (building JEI's index on other threads), idea text only

Measured: offline on JEI's own classes, 2,324,956 checks (2.3 million searches over name, tooltip, mod and tag indexes and 154 edge-case sets) identical, incl. the internal map layout; with 1.5 us of tooltip work per word the 487,810-word tooltip index took 1,199 -> 845 ms in total and its final build step 398 -> 23 ms (loaded machine).

---

jei_sort_index_keys

Since: 1.0.30 · Target: JEI 15.59.0.212 · Side: CLIENT · Kind: opt

Mixins: IngredientSorterMixin, SorterComparatorsAccessor, SortingConfigAccessor, MappedSortingConfigAccessor

JEI ingredient list sorted by precomputed keys. When you join a world JEI sorts its ingredient list (about 40,000 entries here) by mod name, ingredient type and creative-menu position. For every comparison it looks both mod names up again in its list of all mod names, one by one, about 1.3 million times per sort. Now each entry's sort keys are worked out once, with JEI's own functions, and the list is sorted by them. Entries with equal keys keep their order, as before, so the list comes out in exactly the same order. Other sort settings (tag, armour, durability) still use JEI's own sort.

Idea: JEIOptimizer (cheaper single-threaded JEI index build), idea text only; the keyed sort itself is ours

Measured: offline on JEI's own sorter and config classes, 425 sorts (873,838 list positions: this pack's item list with every supported stage order, synthetic lists with ties, partial order files, lists JEI had not seen) came out identical, incl. the list's change counter and the config files written; this pack's list sorted in 383-688 ms -> 63-126 ms (loaded machine).

---

jei_brewing_lookup

Since: 1.0.31 · Target: JEI 15.59.0.212 · Side: CLIENT · Kind: opt

Mixin: BrewingLookupMixin

JEI: find an existing brewing recipe by its ID during recipe generation. JEI checks new brewing recipes against those already found. A lookup belonging to that one build replaces repeated scans of the growing recipe set. The original set still controls membership and iteration order; recipe factories, ingredients and outputs are unchanged. Custom recipe classes, missing IDs and iterator mutations use the original scan. Nothing is cached across recipe builds or world joins.

Measured: transformed-code checks compare identity and order during 20,000 random set mutations. In a focused worker measurement, 10,000 lookups over 5,000 recipes took 0.64 ms instead of 253 ms; this is not a whole-pack timing.

---

jei_tooltip_words

Since: 1.0.31 · Target: JEI 15.59.0.212 · Side: CLIENT · Kind: opt

Mixin: TooltipWordsMixin

JEI: read tooltip search words without regex matching or temporary split arrays. Formatting codes and spaces are scanned directly, producing the same search words in the same set order. Tooltip callbacks, component text and JEI's locale conversion stay on their original thread and run afresh. Dynamic tooltips, language changes, repeated spaces and leading empty words retain JEI's original behavior. Since 1.0.34 every tooltip line is read with the same type check as JEI's own method (1.0.33 refused a line of plain formatted text that JEI itself accepts).

Measured: 20,000 randomized tooltip lists across four locales matched the original transformed JEI method. A focused worker measurement of 30,000 lines took 7.86 ms instead of 12.40 ms, not a whole-pack timing.

---

jei_hidden_menu_sync

Since: 1.0.31 · Target: JEI 15.59.0.212 / Minecraft 1.20.1 · Side: CLIENT · Kind: opt

Mixins: AnvilSimulationMixin, GrindstoneSimulationMixin, HiddenMenuSyncMixin

JEI: skip synchronization scans on its unobserved anvil and grindstone simulation menus. Only JEI's own fake menus qualify, and only while they have no listeners or network synchronizer. Every recipe calculation and slot change still runs, with the anvil and grindstone events. What is skipped is the menu's change scan, which keeps a copy of every slot to notice changes. That scan was also where Forge first set up the item capabilities of JEI's input stacks (AttachCapabilitiesEvent); with the switch this happens when a stack is first used instead, as for any item. If an addon attaches an observer, the scan catches up first, so the observer starts from the current state. Without the switch it would also be told about changes left from anvil steps that end without a result, which vanilla does not scan. No mod in this pack observes these menus. Real player menus are unchanged; generated repair and enchantment recipes stay in JEI. Verified in the full-pack fixture with full-NBT recipe comparisons and a listener attached after a hidden update.