Describe the Bug

I have funnels droping items to depo from big vaults - to have one stack in quick access for players
And it's create lags on server, about 200 us per funnel. All another things from create don't cause tps lag at all

If i change mod of funnel to insert - it's don't have this lag, but there is not so many options to extract from Vaults and i need exactly extract, insert funnels on other side - don't make any lag

Reproduction Steps

1. Make Item Vault of any size
2. Attach any funnel above a depo in extract mode
3. See tps lag wuth Observable profiler
   ...

Expected Result

Don't have this tps lag

Screenshots and Videos

Crash Report or Log

No response

Operating System

Windows 10, Linux (other players on server)

Mod Version

0.5.0i

Minecraft Version

1.19.2

Other Mods

No response

Additional Context

No response

Had this issue in a 1.18.2 server as well, even with relatively small vaults. Pretty major μs/t increases per funnel, even andesite funnels. Kind of like #647 - in that it was mentioned that the funnels are querying individual slots in the structure.

Given how vaults are meant for bulk storage, this feels like an inefficient way to do things. Granted my modding experience is very limited, but could it be more performant to do something like... instead of using so many slots, having a list attached to a specific vault multiblock that stores the items as well as a count, so instead of a vault containing a ton of slots with stacks, it could have:
-An internal list of items and amounts of those items, as well as an associated stack size so it knows how to divide the items into stacks when requested
-A dynamic number of slots, once for each item type in the which holds 1 stack of the item at a time, so that the items are accessible by inventories such as funnels or other modded pipes and stuff

so instead of it having 20 slots being:
[Cobble x64][Cobble x64][Cobble x64][Cobble x64][Cobble x64][Cobble x19][Dirt x64][Dirt x64][Dirt x61][Wooden Sword x1][Ender Pearl x16][Ender Pearl x12][Granite x13][Empty][Empty][Empty][Empty][Empty][Empty][Empty]

it would instead have the 5 slots, and a "total capacity" of however much it would have if the items were still stored in slots, by using the stack size of each item stored inside as well as the amounts to calculate how much space is left. So each "theoretical slot" would add 64 capacity, and an item with a Stack Size of 16 would take 4 capacity, while an unstackable item would take 64 capacity. So something like this:
slots (dynamically created based on types of items inside):
[Cobble x64][Dirt x64][Wooden Sword x1][Ender Pearl x16][Granite x13]
and an internal list saying:
Cobble: 339 (64), Dirt: 61 (64), Wooden Sword: 1 (1) (+NBT), Ender Pearl: 28 (16), Granite: 13 (64)

and when a slot has items taken out, it just pulls from the internal list to repopulate the slot.
this would probably be much more performant for checking for items, though it would need special handling for stockpile switches and the like... Also maybe any item with NBT data having its own slot in case you want to filter unstackables based on enchants or something.

This would make compatability with other mods not perfect, but would still be "good enough" especially given the Item Vault isn't intended to be accessed with ease and is instead meant for automation, mainly using Create Funnels and Belts and the like.

I could be wrong about how much this would help performance but I feel like a list of like a dozen potential items with thousands of them stored would be quicker to check than hundreds of slots filled with potentially identical items limited by stack sizes. I haven't checked but I figure this is probably how mods like AE2 handle so many items at a time. Given how Item Vaults are meant to be used though I think that making them as performant as possible even with super large capacities should be a higher priority than having them work exactly as expected with other mod's item transport and stuff.

Create's storages were changed to use a map to improve the speed of insertion and extraction. The current lag should be constant and not scale with storage size. I would like to optimize further, but it's a lot of work.

Create's storages were changed to use a map to improve the speed of insertion and extraction. The current lag should be constant and not scale with storage size. I would like to optimize further, but it's a lot of work.

Well, if i place exact same funnel not from side, but under the vault - it don't create this tps lag.
Same works for insertion - just place it above

But this fact kinda limited designs for storage, sadly

I tried using a vault for a very compact and convenient setup that takes all washing output and compresses it down from nuggets -> blocks, using a simple filter and limiting a funnel to require 9 items for an extraction. At some point, I started noticing the mobs stuttering around, meaning TPS lag, so I went looking for the culprit. Turns out, it was this vault, cause I hade a mishap somewhere else, causing it to be filled with 10s of thousands of netherack by accident. This apparently causes insane TPS lag, and the entire server gets bogged down to an unpleasant experience from it.

My second funnel takes any compressed items like redstone blocks or iron blocks and sends them off to be sorted, but that one also creates insane TPS lag. Even a simple funnel extracting flint to be burned is extremely bad performance.

After clearing out the vast amounts of netherrack, the TPS is a lot more acceptable, but still, this is kinda problematic I guess.

Before cleaning

The setup

After removing the netherrack

So I guess Vaults are just gonna be performance heavy unless/until something can be done about it?

I wasn't aware villagers were that performance heavy, but I guess it makes sense:

I have another vault-based setup, used for compressing crops into crated blocks, and it has the same issues, even when idling most of the time.

I find the vaults very useful, but now, I don't want to use them at all, when it is this easy to lag out an entire server.

Should be solved by vaults having versioned inventories in Patch g