Lag in TileMaster.getAttachedCables()
LemADEC opened this issue · 4 comments
As of 1.12.2-1.2.8, LagGoggles reports a average 200 µs load on a single Master block.
WarmRoast confirm there's a CPU load in that single block
nota: func_175625_s is getTileEntity
From a quick code review:
- both updateImports() and updateExports() calls the same getAttachedCables() with just a different filter. => consider scanning only once, saving the list of all cables and filtering by type in the loop
- getAttachedCables() will call getTileEntity() twice for each cable
=> consider saving the result of first call
Alternately, we could save a WeakReference to all TileEntities in addInventorys() so we only call getTileEntity() when refreshing the network.
This is a setup with
- 119 storage in 119 Gold chests from IronChests
- 1 import from 1 Diamond chest from IronChests
- 4 exports into 2 Prudentium furnace from Mystical Agriculture.
New code looks much better.
We could pre-allocate the arrays to avoid memory reallocation lag in getAttachedTileEntities() and getAttachedCables().
List<TileCable> attachedCables = Lists.newArrayList();This can be done in the list constructor like so
List<TileCable> attachedCables = new ArrayList(links.size());or after construction like so
List<TileEntity> attachedCables = Lists.newArrayList();
attachedCables.ensureCapacity(connectables.size());
code review is good, that does sound more efficient. Ill look into doing both if it doesnt break anything.
As for the lag, what inventories was it pulling/pushing from? In the past we have looked into lag issues, but it really depends what the other block is doing. For example in this bug report lag goggles was pointing at Storage network , but only because the network was /waiting/ on the request to complete bafomdad/realfilingcabinet#40