Describe the bug
When crafting Mekanism's Ultimate Induction Cells in the Project Ozone 3 mod pack, TPS lag spikes (sky jumps, other machines slow). This is reproducible: it seems to be coming from the AE2 assembly multiblock (or at least it's coding) as providing the full resources for the autocrafting yields the same lag. Notably it gets worse the longer the autocrafting goes on (so calling up more induction cells yields worse and worse lag).

To Reproduce
Set up autocrafting of Mekanism's Ultimate Induction Cells in Project Ozone 3 mod pack, request multiple of these, see lag spike.

Expected behavior
TPS issues should not happen when crafting a relatively simple, but nested recipe.

Additional context

Environment
Project Ozone 3 Titan Mode 3.2.55

• Minecraft Version: 1.12.2
• AE2 Version: rv6-stable-7
• Forge Version: 1.12.2

We need an actual sampling or profiling report for it.

Most likely it is even related to some external inventory or crafting recipe.

There's not external inventory associated with these crafts.

I tracked it down to my use of ore-dictionary in the recipes owing to Mekanism not assigning unique identifiers to each of the subcraft outputs. When fixing the recipes -- unselecting the ore-dictionary checkbox, and recreating the recipes using actually produced subcraft outputs -- the TPS lag was much reduced and almost not noticeable (brief quarter second pauses every 13 or so seconds). I think this can be partially fixed on AE2's side -- I suspect the ore-dictionary check box is causing the code to search through items in the crafting store/list to complete the craft, when in point of principle with nested crafting, the system theoretically could already have a list required for each step: ie the output from the prior step could be first attempted, the only one tried given the nested crafting has been engineered to work this way, etc. There are probably several ways to make the ore-dictionary code more efficient in its search -- perhaps a better database of recipes and available resources?

the system theoretically could already have a list required for each step: ie the output from the prior step could be first attempted

what you describe is technically wrong ... how to do you even know the prior crafting steps when you actually only know the end product to make? crafting is simulated top down, from the end product through its ingredients (if they are present) and subsequent iterations of subingredients (if missing), this is where the calculation effort lies

disclaimer: i may have misunderstand what you were trying to say but it sounded like "why search when i have the prior products at hand" (where you dont even know if you have em)

Ok, that explains it mostly. Mekanism is particularly bad due to how their items are organised into multiple different ones sharing the same id. For us there is no way to distinguish between the subtypes (in a sane way). So we have to stuff every item into the recipe until it might fit.

But this also triggers the fallback to try for alternative recipes. Because just because the tested recipe does not accept it, there still might be a different one for the same output but different inputs, which actually accepts the current inputs. That is also something mekanism does.
The real downside here is that forge then is really bad at this part. Their solution is to test every single existing recipe until some accepts it. Or none.

This is also nothing we can cache as Forge does not provide any way to distinguish between NBT tags, which are required and the ones which can be ignored. So we would have to cache every single permutation of an item, which can easily be a couple million instances for something like a battery block. Which would be a huge waste of memory and it would have to iterate over millions of entries to find one stored in the network.