Massive performance impact from single nodes
Corbi84 opened this issue · 11 comments
LaserIO version
1.6.7
Minecraft Version
1.20.1
Forge Version
47.2.16
Modpack & Version
ATM9 0.2.32
Do you have optifine installed?
No
Describe the issue
A single overclocked (card oc, not node oc) lasernode brings the server down to around 5 TPS. In this case it is a node with only two cards, one insert and one extract set to 64 items/tick. Already had the same problem in ATM8. The node doesn't even need to be transferring anything, just having it sitting there will do the trick. Removed it and the TPS went back up to 20.
Steps to reproduce
- place node
- insert cards
- overclock
- check with /forge tps and/or performance analyzer
Expected behaviour
Very low impact on performance, since they are used as an alternative to cabling, aka in masses.
Screenshots
Log files
No response
Additional information
No response
Hi Dire,
modded blocks in both modpacks. In ATM9 it connected an Occultism Dimensional Storage Actuator (mass storage) with a Dank Dock.
In ATM8 it were an Ender Chest and a Storage Controller from Functional Storage.
I did not expect such a quick reply... ^^
Need the server admin for that, since I can't run the profiler. But will upload it later today. (it's morning now in my timezone)
Just as an fyi: So far can reproduce it reliably be placing the node and inserting the cards with the card overclocker. TPS will go down immediately to 10 and after a few seconds to 5. As soon as the node is broken, it goes back up to 20. Increasing the item count does not cause any problems, but as soon as I increase the speed TPS start going down.
The spark profile: https://spark.lucko.me/enD0vHHSL8
Is there an item in the filter? Or an item that is in the inventory? Does it have a ton of data on it or something ? This is weird.
The input card towards the dank dock (without the dank itself) has an item filter for cobblestone. The extract card has no filter, but there are thousands of items in the storage actuator from Occultism. It's a mass storage similar to ME systems, currently somewhere at 1600-something "stacks" of items counting from 1 to 1024 each. Occultism counts in "stacks" of 1024 items and provides various possible stacks with the tiered Dimensional Storage Stabilzers.
In ATM8 it was the other way round, the overclocked extract card connected to an Ender Chest as a main input into the system and the insert card was connected to a Storage Controller which in turn was connected to a room of storage drawers.
I'm wondering if its just the massive number of itemstacks that the node is interacting with. I'm assuming with such a large "inventory" it has a lot of work to do to figure out where to place items.
I'll see if I can reproduce, for now I'd say just avoid using it with the occultism mass storage system.
At the risk of opening the ticket again:
Thanks for looking into it!
Does that work both ways? Asking, since I had the same problem while inserting from an Ender Chest (upped to 27 slots with Ender Pearls, which doesn't sound too bad) into a storage controller from Functional Storage. Seems likely to me since drawer networks can get pretty big and the that way around it needs to check for available space.
If you are interested in further looking into it, the mod Cable Tiers might potentially be interesting for a sneaky peak at the coding. It adds pretty insane im-/exporters, which don't seem to effect servers that harshly.
Yup insert tries to insert until successful so if there’s 1000 slots it doesn’t fit into it tries 1000 times until it finds an open slot.
What I could do is limit the amount of slots you can check per tick. But that’s really no different than only trying to insert every 20 ticks :).
It also “sort of” remembers the last slot that worked but that’s not always perfect. Especially for non stacking items like swords.
So that method iterates over all the 'slots' in an inventory to try to exact something from it. Chests, for example, have 27 slots to iterate over. Diamond chests 81. Occultism has.....over 1000? :) Yea I guess I can see how that might sting.
My only suggestion is to avoid using high speed (once per tick) on inventories of such a large potential size. Any other solution would be far too complex to implement, especially for such an unusual edge case.