Repository navigation
[0.8.2a] ME Bridge rebuilds the whole AE2 inventory cache every tick, even with no computer attached #854
Description
Describe
On 0.8.2a the ME Bridge costs server tick time proportional to the size of the ME network every tick, even with no computer attached and no Lua calls.
PeripheralBlockEntity.handleTick calls MEBridgePeripheral.update() every tick, and update() calls IStorageService.getCachedInventory(). In AE2 19.2.x the cache is marked dirty at the end of every tick when there are no storage watchers (StorageService.onServerEndTick), so each call rebuilds the whole network inventory (getAvailableStacks over every cell plus a watcher-diff pass). The disk check then only needs that full inventory every 20 ticks (diskRescanCD), and the lastDisks check could use getInventory().extract(..., SIMULATE) / getAvailableStacks per key instead of the full cache.
Measured with a spark-confirmed tick timer on a headless server (NeoForge 21.1.264, AE2 19.2.18), network with N item types in 256k cells, ME Bridge placed, nothing connected to it:
| Item types | Tick time without bridge | With ME Bridge 0.8.2a | With ME Bridge 0.7.62b |
|---|---|---|---|
| 1,000 | 0.32 ms | 0.83 ms | 0.33 ms |
| 10,000 | 0.30 ms | 4.3 ms | 0.31 ms |
| 30,000 | 0.33 ms | 12.6 ms | 0.30 ms |
A JFR profile attributes ~63% of server-thread samples at 30k types to MEBridgePeripheral.update → StorageService.getCachedInventory → updateCachedStacks. 0.7.62b has no update() override and no such cost.
Steps to reproduce
- AE2 network with a large number of item types (e.g. 10k+).
- Place an ME Bridge on it. No computer needed.
- Compare MSPT (spark) with and without the bridge.
Multiplayer?
Yes
Version
1.21.1-0.8.2a (Latest 1.21.1)
Minecraft, Forge and maybe other related mods versions
Minecraft 1.21.1, NeoForge 21.1.264, AE2 19.2.18, CC:Tweaked 1.120.2
Activity
do not keep scanning inventory when no computer disk present in ME ne…
dargabi commentedon Oct 22, 2026
Thanks for the quick fix! One thing left though: with no disks the rescan still calls
getCachedInventory()every 20 ticks, and since usually nothing else reads the cache in that tick, it's a full rebuild every time. On my 30k-type test network that's around 15 ms once a second. Much better on average, but it's still a small spike every second on big networks.Since the disks are cells sitting in drives anyway, maybe the rescan could just walk the drives (like
streamCellinAEApialready does) and look forAEDiskCellItemthere, instead of going through the whole network inventory? That way it scales with the number of drives, not item types. Unless disks can show up in the network some other way that I'm missing.