Issue type:

• 🐌 Performance issue

Short description:

I placed 8 additional chests with item interfaces to extend my storage network, then I noticed massive tick lag.
When I remove the item interfaces the lag is gone again.

Steps to reproduce the problem:

1. start up dw20 mc1.20 version 1.12.1
2. setup network with 8 chests
3. add many hundreds of items
4. add item interfaces to chests and several exporter/ importer
5. lag

This is what we have on a server basically.
Testing on SP didn't seem so easy to reproduce. Is there performence issue when certain items are in the system?

I will try to get a server profiling report with spark in the following days. Need to ask admin first

Versions:

• This mod: 1.20.1-1.8.24
• Minecraft: 1.20.1
• Forge: 47.1.84 (Neoforge)

Profiler output:

Client side reports:

2024-02-27_23_23_29-Picard-1_20_1 without chest interfaces.zip

2024-02-27_23_26_26-Picard-1_20_1 without chest interfaces.zip

Hmm I have many exporters on that network. How exactly do I check the ID network diagnostics to see which one is expensive?
The exporters are mainly just exporting certain items or a short list of items, as I'm relatively new to the mod.

\integrateddynamics networkdiagnostics

Thanks for reporting!

I will try to get a server profiling report with spark in the following days. Need to ask admin first

That would be great! :-)
Putting this issue on hold until then.

Ok managed to check it:
wZGSnDsXqD.zip

The cause is definitely from IntegratedTunnels:

Inside the IntegratedTunnels part there is a lambda which causes some issues here:

We have setup a testing server where the savegame with issues is on. If you have any more questions about Blocks or Items we have at certain positions I can go check that out.

Thanks for looking at it.

@judos Do you have a URL to the spark log?

@rubensworks no, the url from spark didn't work, but we exported the data (see above zip file) this one you can drag & drop onto the field at https://spark.lucko.me/
That gave me the data as in the screenshot. Is that enough? Or is there something missing in that?

If necessary we could restart the testing server and keep the profiling running, while it is live the spark url worked I think.

spark

spark is a performance profiler for Minecraft clients, servers, and proxies.

Aha, TIL that spark works like that :-)

@judos It looks like you have some kind of expensive export operation that is not able to exploit the indexes of the network. Could you let me know which exporters you have programmed on that network? (you could also check the ID network diagnostics to see which exporters are the most expensive TPS-wise)

Note to self:

That's a cool diagnostics you got there :)
The component doesn't look special to me. Item Exporter exporting Wax + Charcoal into an already full Iron Chest.

Changed the chest to a normal vanilla Wooden Chest. Still changes between 7ms and 15ms just to export items into a full chest.

Does that help you to reproduce the issue?

Further settings:
Channel 0
round-robin: False
blacklist: False
Transfer rate 64
Item Slot -1
Passive interaction: True
Check Stack Size: False
Check NBT: False

Changing to only fill into Slot 0 reduces time usage significantly. But this shouldn't be a requirement.

Changing to a Variable Card with only Item Charcoal or Item Wax uses 0.04ms.
So something in the code when using a Type List with multiple Items is causing issues.

Note to self:

Problem is that IngredientPredicateItemStackList can not make use of matchflags-based indexes.
Let's extend IngredientPredicate so that it accepts a disjunctive list of ingredients on which matchflags can be applied.
Then we'll have to do some looping in the ingredient movement logic.
Change in 1.18 and above.