I noticed the load on the server and decided to inform you
I hope for optimization
https://spark.lucko.me/hu0lp89vqI?hl=8061,8129

sophisticatedcore-1.20.1-0.6.35.733

Well, how do you imagine that cache to work exactly? I mean every slot can have a different filter or different stack already in it so a "cache" for this would need to remember if the given stack that was passed in was valid or not for the give slot resulting into a map of slot to multiple stacks with true/false for every single slot in cases where the inventory is full. That would make performance of lookup in this "cache" to be much worse than what it is now or at least in those cases where inventory is mostly full.
And the slot limit would be a list of slot to slot limit which could be marginally better than traversing the inventory handler here - you could probably save like 0.01% from those 3% here on that, but that to me is in no way anything I want to pursue given that any cache also needs to be properly updated and thus it would complicate the code even more and likely introduce bugs.

Anyway, not sure if I was clear, but there's way better way of handling this

• with Input block / controller combo the number of iterations pipes have to run for that cluster of botany pots goes down from 73,728 to 256 so if the percentage went down in the similar way it would get down to about 0.01% spent in sophisticatedcore
• with void upgrades it's the same number of iterations that is 256 because of how internally inserts work in sophisticatedcore and because botany pots likely don't produce resources every single tick it would mean pipe wouldn't have to try to insert that item next tick again

I didn't quite understand about "Setup" I use a translator
Are you talking about what the mechanism diagram looks like?

What I meant by setup was what kind storage the mekanism pipe is pushing into- is it single storage block or is it controller with multiple blocks? And is it just pipe inputing from single botany pot or are there multiple? Are any of the items full in the target storage and thus pipe is not able to insert them?

Players place a large number of pots under them the same number of pipes and transfer to a double netherite chest with "Netherite stack" upgrades

And multiply this by 10 since I noticed 10 players with such schemes

It looked something like this, only instead of interfaces there were chests and the pipes were made of mekanism

Right so with this kind of setup even with just a double chest as a target if that double chest is full of that given product of the botany pot the pipe has to check 288 slots for that given item to figure out it can't fit in there and most of the pipes would do that every tick. Now if there are multiple items that can't fit in the double chest anymore you just multiply 288 with the number of the items so if this setup in the image was pointed to full double chest where no items can fit anymore the pipe would have to check 256 * 288 slots every tick = 73,728 times every tick.
It can be optimized by adding controller and input block and pointing the pipe to the input block - input block only exposes 1 slot and so the pipe will have to do this operation 256 times per tick. But you probably also want those players to either stop those pipes from working when target is full or use void upgrades so that there's always space for the item in the target and pipes don't need to be that busy.

Anyway there's nothing obvious to optimize on my side and I doubt there will be much to optimize for those pipes when I am seeing setups like this which can pretty easily take a huge part of tick time.

@P3pp3rF1y At the very least, you can probably add a cache for validation and a slot limit! It certainly won't be superfluous

Why do you feel there's an issue here? There's less than 3% of the time spent in sophisticatedcore code with that botany pot code alone spending 13% of the time here with the core time excluded. There's probably something that can be optimized there, but my guess would be that you have mek pipe pushing into storage controller that's connected to a number of storages and there's no place for the given item to go. So what mek pipe does in that case is that it goes through every single slot present in that storage mutliblock and tries to insert in there without success and it does this logic every single tick. Pretty big optimization can be achieved by using Storage Input block as the target for the pipe because that makes the pipe only try this once per tick. However you likely want to free space for the item or use void upgrades so that excess is voided in there and this doesn't bog down your performance.

Let me know if you have any other info here like what your setup actually looks like, but from this trace there's nothing to optimize here.