Issue type:

• 🐛 Bug

Short description:

Piping items in to an importer causes lag. In my case, the world would go from < 3 ms/t to over 30 ms/t, even spiking to 60 ms/t. Piping them in to a chest and then importing them from the chest using an item importer immediately resolved my lag.

Steps to reproduce the problem:

1. Pipe items in to item importer set to import all items
2. Server lags

Expected behaviour:

Piping items in to an item importer should import the items in to your network without creating significant lag.

Versions:

• Integrated Dynamics: 1.12.2-1.0.14
• Integrated Crafting: 1.12.2-1.0.7
• Integrated Terminals: 1.12.2-1.0.8
• Integrated Tunnels: 1.12.2-1.6.9
• Minecraft: 1.12.2
• Forge: 14.23.5.2837

@Naosyth Could you share your profiling output as described here?: https://github.com/CyclopsMC/CyclopsCore/blob/master-1.12/.github/CONTRIBUTING.md#performance-issues-snail

GitHub

CyclopsMC/CyclopsCore

Minecraft library mod for EvilCraft, Integrated Dynamics and others. - CyclopsMC/CyclopsCore

@rubensworks Sure:
sample_piping_to_importer.zip

This is my test set up, for reference, piping in a steady steam of cobblestone:

While the servo was active, the time per tick for that dimension went from 3 ms to 30 ms

Note to self:

There are two main problems:

1. In CommonCaps ItemStorageWrapper#getStackInSlot becomes expensive due to the Iterators.get(storage.iterator(), slot) call on networks with many slots. It would be better if this iterator would be more efficiently offsettable.
2. Iteration in CyclopsCore over a IngredientCollectionPrototypeMap is expensive for ItemStacks, as a lazy transform stream will apply quantities to each ItemStack, which causes copy() calls, which will trigger semi-expensive gatherCapabilities() calls.

Possible solutions:

1. Make offsetable iterators, or make the .next() call return a lazy item, which would avoid the costly copy() calls.
2. Modify IngredientCollectionPrototypeMap so that no lazy transform iterator is needed.