Describe the bug
Having a lot of items inside the backpack, that themselves have a lot of items inside of them (or an equivalent high amount of nbt data) will cause extreme lag on the client and server, especially when holding the backpack or having it open.

To Reproduce
Steps to reproduce the behavior:
Create a deeply nested backpack with a lot of different items/item types. I easily experienced this bug by transferring AE2 storage cells, containing tens of thousand of items. This may not be experienced in normal gameplay, but certainly in modpacks where bulk-storage items such as storage cells are common.

Expected behavior
At least not that much lag. It appears that the same amount of nested items (or in my case storage cells) inside of a chest (ctrl+middle mouse click to obtain chest with nbt as item) will also cause tremendous lag, but with backpacks it's a significant amount more. So this seems to be a forge/minecraft problem at core, but something makes it even worse with these backpacks.
My suspicion is that in this line

the backpack compares nbt data every tick when equipped, which might be quite cpu intensive with large nbt structures

Screenshots
-/-

Versions

• Mod version: 1.16.5-1.12.0.88
• Minecraft version: 1.16.5
• Forge version: 36.0.46
• UTeamCore version: 3.2.0.193

Log (if crash occures)
-/-

Yes, this is unfortunately a fundamental problem with minecraft item stacks and their creative system.
The method ItemStack.areItemsEqual (oldStack, newStack); compares the article without the tags. The compare shouldn't actually be responsible for the lag in this case.

The main problem is that the data is stored in the nbt tag and will be send to the client if something changes (item drop, etc).
A capability would probably be better but the main issue with all of this is, that the creative mode is authoritative and needs all nbt and cabability data. If something is missing then the backpack loses its content which is not very useful. There is an option in the server config which removes the backpack nbt data from the packet to the client: shareAllNBTData but this has the creative problems as discussed in #24

As an end result, I might need to do some testing where the main lag is, but it's unlikely to be fixed.