Metadata

Dropping metadata should be mostly trivial. Nevertheless it allows some internal redesigns.

For example we could drop the NavigableMap with O(log n) for most operations with a HashMap or even IdentityHashMap with the item id as key and a custom collection for the values. E.g. a HashMap like structure for non damagable items but multiple instances with different NBT data and a NavigableMap like one for damage able to have efficient range queries for fuzzy modes.

But this needs some performance tests to confirm that O(1) + O(1) (or O(1) + O(log m) for fuzzy) is actually an improvement over the current O(log n)

Tags

As we already abstract the OreDictionary itself, it should be easy to switch it.

It might be an idea to test how a local Map<Tag, Collection<Item>> performs in terms of cpu and memory consumption in comparison to a global cache with a list of all items, which then have to fetched separately and combined. But with tags appearing to be limited to the actual id, a layered structure might make it easy to just fetch all matching ids.

Other changes

ItemList is currently self healing to drop invalid entries instead of leaking them. But this requires a concurrent collection, otherwise we run into ConcurrentModificationExceptions occasionally. This might make it impossible to use a IdentityHashMap without using a different approach.

The current approach is to immediately remove an entry once isMeaningful() is false as part of the Iterator, which ultimately causes the ConcurrentModificationException.

An initial scan is will have a negative effect on the performance as it will cause the collections to be iterated twice. Collection all invalid entries and removing it after the last iteration might work, but can still result in some negative effects. E.g. needing to revalidate the itemstack again to avoid dropping a now meaningful stack.

Another solution might be to switch to some managed collections. E.g. have a central factory, which keeps a (weak) reference to each created one an periodically compact them as first/last job each tick. But this might not result in a better performance, should the majority of ItemList instances never or very rarely be iterated.