Storage Drawers

Storage Drawers

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.

Two controls for Storage Drawers 12.15.1 (mod id storagedrawers): count labels are formatted once per count (client), and count updates go only to players who can hold the drawer's chunk. 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
storagedrawers_count_label_memo	Storage Drawers 12.15.1	CLIENT	1.0.28	opt
storagedrawers_count_sync_holders	Storage Drawers 1.20.1-12.15.1	BOTH	1.0.30	opt

---

storagedrawers_count_label_memo

Since: 1.0.28 · Target: Storage Drawers 12.15.1 · Side: CLIENT · Kind: opt

Mixin: CountFormatterMixin

Storage Drawers count labels formatted once per count. With the Quantify Key, every drawer face in view formats its item count every frame, and every count from 10,000 up goes through String.format ("12.3K", "45M"): a new formatter and float formatting per slot per frame. On the render thread each such call now looks up a table keyed by every input String.format uses (the format, the number and the current locale) and returns the text it produced before; the table holds up to 2,048 labels and is cleared when full. Smaller counts and other threads are formatted as before.

Measured: 323 -> 13 ns per label on real classes (100 -> 8 us per frame for 256 labels); 2,520,218 checks identical, locale switches included.

---

storagedrawers_count_sync_holders

Since: 1.0.30 · Target: Storage Drawers 1.20.1-12.15.1 · Side: BOTH (server logic; singleplayer runs it on the integrated server) · Kind: opt

Mixins: DrawerCountSyncMixin, CompDrawerCountSyncMixin, PlayerListCountSyncMixin

Storage Drawers: drawer count updates only to players who can hold the drawer's chunk. Every change of a drawer's stored amount (a hopper or pipe moving items, every slot of a shift-click deposit) sent a count update to every player of the dimension within 500 blocks, standard and compacting drawers alike. A client that does not hold the drawer's chunk looks the drawer up, finds nothing and drops the update, so each of those sends cost the server a packet hand-off, an encode and the bytes on the wire for nothing. The update now skips players outside the chunk's tracking set (ChunkMap.getPlayers, the set vanilla sends block changes to; mods that show chunks elsewhere, such as SecurityCraft cameras and Valkyrien Skies ships, extend that set). Everyone else gets the same packet in the same order on the same tick: the 500-block distance, the dimension test and other mods' changes to the broadcast are untouched, and every skipped packet is one the client would have discarded. When the drawer's dimension has at most one player (singleplayer included) the update is sent exactly as before, without the check. Without Storage Drawers nothing is applied; with it, every broadcast other than a drawer count update is unchanged.

Measured: offline on the real PlayerList.broadcast and ChunkMap.getPlayers in 4,000 random player layouts (both dimensions, view distance 2-32, 778 of them with at most one player in the dimension): the recipients were exactly the original's recipients that hold the chunk, in the same order, and exactly the original's with one player (25,557 checks). Each skipped recipient saves about 0.4 us of encode and send work and 38 bytes on the wire; with 2 players at the drawer and 8 more within 500 blocks a count update took 1.1 us instead of 4.5 us. Singleplayer costs nothing extra (421 vs 418 ns); two players who both hold the chunk pay about 0.1 us per count update.