this was from someone system that was linked and causing lag and they wrote this up for me, please review.

Modpack: ATM7 to the Sky
Modpack Ver: 1.1.0
Forge:40.1.80
Minecraft: 1.18.2

So QIO is like a LITE version of AE2 in how it handles item storage, it stores items on disks in drives. In order to interact with that inventory (VIA IO or Terminals) the server needs to know what's inside the Disks, for both QIO and AE. So the server runs a check on the drives, checking what's in them as well as how much space is available and stack limits etc. Both AE and QIO do this similarly, and separate it's not really a problem. AE native storage is pretty severely limited, so it's rare to have massive amounts of items being 'indexed' by the MEStorage.getAvailableStacks function. Even with storage busses on inventories like drawers that can have large quantities, it's no big deal because the drawers themselves aren't running their own functions and indexing their inventories.

However, QIO systems do run checks on its inventory, every tick just like AE2 and can hold massive amounts of items. I have a Supermassive QIO drive with 4.1 Billion items on it, which by itself is causing lag when Mekanism calls its own QIO.forAllStored() function. The issue is compounded when you use Applied Mekanistics to link your QIO inventory with your AE2 system. Both AE and QIO still run the same checks on their respective inventories, essentially indexing the contents twice. This causes any lag generated from large quantity item storage in QIO to be doubled, as AE now has to index the same items that QIO did.

The QIO.forAllStored() function was taking 77,058 MS to run when Mekanism called it, then when AE storage bus was connected to a QIO dashboard the AE version of that function (MEStorage.getAvailableStacks) took 77,117.ms re-calling the exact same QIO function. The standard NetworkStorage.getAvailableStacks() that applies to AE's own network storage took only 897ms. When I unhooked my QIO dashboard from my AE system, QIO no longer ran that function (lowering Mekanism total MS from 168,000 to just over 90,000) and AE no longer called the QIO function either. This increased total TPS from 8 to 13. Reconnection the QIO to AE system resulted in the same drop in TPS and spike in MS from QIO/AE interactions. All numbers from Spark report.

Original Spark Report: https://spark.lucko.me/DxR7U19QR2
Spark Report after Unhooking QIO from AE: https://spark.lucko.me/esuiUzTZBL
Spark Report after Reconnecting QIO to AE: https://spark.lucko.me/5cSC4JWX8e

You'll find the referenced numbers/functions under the mods view at the top of the page.

It looks like this is only an issue on systems with massive amounts of different "types" of items, the original setup had over 3100 different types stored in QIO. After moving all but 53 types off my QIO drives (every type less than 4 million) to AE2 drives, I'm left with 3.7 billion items in QIO still and significantly reduced lag.

QIOFrequency.forAllStored() is running at 430.97ms with this configuration, compared to 77,058 when all items were stored in QIO. With all the types stored in AE2, NetworkStorage.getAvailableStacks() is running at 11,849ms instead of the original 897ms.

Spark Report: https://spark.lucko.me/MalEw3WTGr

Thanks for the detailed report! I will have a look at some point to optimize our interaction to allow for more item types without too much lag, but in any case the total number of item types needs to remain small enough for AE2 not to cause lag.

It appears to be a QIO issue regarding item types. When the items were all stored in QIO, the QIO function was generating insane lag, and since AE calls that same function from the QIO code again it caused AE to generate the same insane lag a second time. Now that the items are in AE2 instead, AE is generating 1/7th the amount of lag QIO was and QIO is generating hardly any at all. Moving the non-bulk storage to AE was what lowered the lag. Maybe this is something I should post for the Mekanism devs as well since it seems like its related to how QIO handles types. AE is just calling QIO's function to index the items, so I think the issue is in there.

response from reported player, thanks for speed response.,

This particular Mekanism function invocation actually interacts with AE2 internally, so the blame is shared. :P
I will discuss with the Mekanism devs, don't worry.

Mind testing this jar (inside the zip)?
Applied-Mekanistics-1.3.3.zip

@ramidzkh did this ever get PR'ed?