ImmediatelyFast

ImmediatelyFast

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.

Three controls for ImmediatelyFast 1.5.5 (Forge, +1.20.4 build) (mod id immediatelyfast), all client-side: render-layer ordering compares path prefixes in place, HUD batching stays on with Call of Yucutan's entity shader, and flushes skip idle layers. 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
immediatelyfast_idle_layer_skip	ImmediatelyFast 1.5.5+1.20.4 (Forge)	CLIENT	1.0.28	opt
immediatelyfast_known_core_shaders	ImmediatelyFast 1.5.5	CLIENT	1.0.22	opt
immediatelyfast_offset_layer_prefixes	ImmediatelyFast 1.5.5	CLIENT	1.0.14	opt

---

immediatelyfast_offset_layer_prefixes

Since: 1.0.14 · Script (1.0.19 and earlier): furious14-substrings.js Patched: net.raphimc.immediatelyfast.feature.core.BatchableBufferSource.getLayerOrder Mixin (since 1.0.20): BatchableBufferSourceLayerOrderMixin

What upstream did. When sorting horse and villager render layers, ImmediatelyFast stripped the common texture-path prefix with substring, then performed further prefix checks on the new string, allocating twice per comparison.

What the patch does. Replaces the suffix-string constructions with String.startsWith(suffix, offset) against the original path.

What stays the same. Every ordering branch, every special layer priority and the comparator behaviour. Tests included exact prefixes, truncated paths, matching and non-matching suffixes and Unicode paths.

Measured. Horse layer ordering 28.85 → 15.46 ns (−46.4 %, 64 → 0 B); villager layer ordering 39.82 → 27.88 ns (−30.0 %, 64 → 0 B). Sorting cost outside these branches is unaffected.

Fixed in 1.0.20. From 1.0.14 to 1.0.19 the patch left the third villager check (profession_level/) without its offset, so villager level badges got layer order 1 (the villager base layer) instead of ImmediatelyFast's 4 and were batched with the base layer. The mixin puts all three villager checks at the right offset; 49 texture-path cases, covering every horse and villager path shape, give the installed ImmediatelyFast order.

---

immediatelyfast_known_core_shaders

Since: 1.0.22 · Mixin: KnownCoreShaderMixin · Helper: bons.furious.patch.immediatelyfast.KnownCoreShaders Patched: the resource lookups inside ImmediatelyFast's MixinGameRenderer.checkForCoreShaderModifications (wrapped; CoreShaderBlacklist fingerprinted)

What upstream did. ImmediatelyFast switches HUD batching off after every resource reload when a non-vanilla pack replaces one of the core shaders on its blacklist. Call of Yucutan 1.0.13 replaces rendertype_entity_translucent_cull.fsh through Forge's combined mod_resources pack, which cannot carry ImmediatelyFast's compatibility metadata, so HUD batching was off in every session of the pack this was built in (84 logs since August).

What the patch does. That one file is vanilla's shader plus one per-pixel branch (alpha 254/255 = unlit, an emissive marker) and uses the same inputs and uniforms, so it is recognised by its exact SHA-256 and no longer counts against HUD batching. Any other file at that path, or any other blacklisted shader, is decided by ImmediatelyFast as before. The log says … is a known batching-safe file; it does not switch HUD batching off.

What stays the same. What the HUD draws: with batching on, the HUD with Call of Yucutan's emissive items rendered the same as unbatched (screenshots in the rig runs).

Measured. HUD batching stays on in game (runtimeConfig.hud_batching=true). HUD draw submission was about 1.1 % of the render thread in earlier profiles, so up to about 1 % (a ceiling, not a measurement).

Note. The same check also decides ImmediatelyFast's font atlas resizing, so that stays on as well. Text is drawn with the rendertype_text shaders, which Call of Yucutan does not replace.

---

immediatelyfast_idle_layer_skip

Since: 1.0.28 · Target: ImmediatelyFast 1.5.5+1.20.4 (Forge) · Side: CLIENT · Kind: opt

Mixin: BatchableBufferSourceIdleMixin

ImmediatelyFast flushes skip idle layers. ImmediatelyFast's batching buffer source ends every fixed layer (29 in vanilla, more with mods) on each flush, wrapping each one in a new one-element set although almost none were drawn into. In the review-8 profile that class was 2.5-4.2% of the render thread's allocation. A flush now leaves out a layer only when ending it could not draw or change anything but one Iris flag, which ends where ImmediatelyFast leaves it. Fixed builders are ended without the set, lookups are single, drawn fallback sets are reused, and new sources start small. Subclasses keep ImmediatelyFast's code in full.

Measured: GUI flush 1,179 ns and 2,152 B -> 743 ns and 504 B; world flush 1,422 ns and 2,811 B -> 1,101 ns and 1,163 B, on real classes; 478,984 checks identical.

---

Candidates that were measured and withheld

For completeness, one ImmediatelyFast idea was fully implemented, passed its correctness tests, and was not shipped because native timing regressed:

• ImmediatelyFast fallback-buffer lookup (BatchableBufferSource.getOrCreateBufferBuilder, 1.0.14 batch): 7.8 % slower on the native hot path; a variant was 31.6 % slower and allocated 32 B. HotSpot had already eliminated the original iterator.

Its patch and switch are absent from every release; the original method stays active.