Current Behavior

It seems that whole CTArtisanBuilder takes about 83mb of memory. It it much. I added about 1k of recipes.

Then I checked it deeply it seems that there are Recipe entries 136kb each but 135kb is taken by tools. All tools entry are same and each takes 45kb or memory.

The ToolEntry contains toolStacks and toolItemStacks arrays. There are 23 entries in each of them, and I got 23 tools for each kind, so it seems that it stores all possible tools inside it. Also toolItemStack contains many ItemStack entries but toolStacks also contain ItemStack but wrapped in ArtisanItemStack. I'm not saying it shoudn't, just mentioning it.

Expected Behavior

I expect ArtisanWorktables to use less RAM if it is possible. So I humbly ask to optimize it somehow. Maybe by not storing 2 arrays, maybe by storing only a reference to tool and not itemstack itself, maybe cache tools arrays somehow as they are not changed after recipes got loaded (at least for tools from your mod as they are usually used together) and etc. I'm sorry I can't say a proper way, I'm not a java developer.

My reasoning is simple:
1k of recipes takes 80mb and increases in algebraic progression. It depends on how many tools there are in recipe (3 tools recipe take 135kb, 2 tool recipe 90kb etc.) but still 2k of recipes would be around 160 and so on and so forth. For a big modpack having 3k and even 5k of recipes is not such a big deal and this can take more and more memory so it should be optimized if it is possible. 1.12.2 is known for eating much RAM and no need to increase it further. Of course this is relevant only then you use dictionary for whole tool kind (like all drivers or all mortars), but I believe it is being used in most cases.

Your Environment

• Minecraft: 1.12.2
• Forge: 14.23.5.2847
• CraftTweaker: 1.12-4.1.20.615
• Artisan Worktables: 1.12.2-1.24.1
• Artisan Automation: none
• Artisan Integrations: none
• Artisan Workstumps: none
• Athenaeum: 1.12.2-1.19.2

Thank you for the report!

I have performed multiple optimizations, testing using 2,187 Workshop tier recipes each with three oredict tools and seven shaped ingredients.

First Optimization

This optimization eliminates the unnecessary duplicate collection of item stacks in the ToolEntry class with no trade-off. The results indicate a 53.7% reduction in retained heap size.

Before:

After:

Second Optimization

This optimization shifts the JEI recipe wrapper burden from RAM to CPU by generating the required data on-demand as opposed to caching it in class fields. The results indicate a 99.8% reduction in retained heap size. Any burst of RAM and CPU usage during JEI usage is temporary and an acceptable trade-off for this optimization.

Before:

After:

Third Optimization

This optimization introduces a thread local static cache to cache ToolEntry item stack references that have equivalent item and meta values. Item stacks with NBT data are not cached. The results indicate a further 86% reduction in retained heap size.

Before:

After: