What happened?

Performance is simply extremely poor during mapload, it shouldn't take ~90 seconds to parse 1500 recipes.

How do you trigger this bug?

Load the game in Enigmatica 6 Expert. Loading times are slightly less horrible due to less recipes in regular Enigmatica 6.

Forge Version

36.2.29

Mod Version

Diet 1.16.5 - 1.0.2.3

Other Relevant Mod Versions

Enigmatic 6 Version 1.0.0

Relevant Log Outputs

Profiler snapshot pictured:
https://files.catbox.moe/yq8dje.nps

Note in particular how it's all self time in traverseRecipes, I'm not sure why traverseRecipes is so expensive, but it is.

Any update on this? I'm getting ready for the next Diet update and I'd like to know if I should wait for this, save it for a future update, or work on my own solution.

It's performance heavy because of how it needs to recursively traverse the recipes for each ingredient of each recipe to build out any missing Diet values, so it's processing much more than just the number of total recipes. I have always been concerned about the performance implications and tried to code it as optimized as possible, but it seems it was not enough and I'll have to take more aggressive measures.

I don't believe Enigmatica 6 Expert is released anywhere, at least nowhere I can find. Is there a link to it that I can use for debugging, or can I also use normal Enigmatica 6?

I should be able to get this done today, I'm on it right now.

Only one way matters, so multiple recipes can be ignored if one is already found. However, it's important that this is done deterministically so that, for any particular set of recipes, the same recipe is always chosen for that particular item.

Thank you, it having to be deterministic makes a lot of sense. Is that why you sort the list by ID?
Any recommendations for food mods to test it with? I'll test the final implementation with Enigmatica but it's not suitable for small incremental tweaks as startup+ world loading takes >15 minutes for me.
Mostly looking for ways to exercise the recipe traversal code more than just Vanilla items do.

I'm happy to take a look at the code as well, will get back to you once I've done so

For Enigmatica 6 Expert, get Normal Enigmatica 6, then in-game do /mode expert, I think you also need to reload your world and/or restart the game(?). Normal Enigmatica 6 should be sufficient for testing as well, thought recipe traversal takes 1.5x as long in Expert. The profiling snapshots were done by waiting for the log messages associated with parsing to appear and then hitting start profile in JvisualVM.

Alright, this is unfortunately graph traversal, which is hard. That said I have a few ideas, I'll have to look into getting compilation set up

You don't have to trouble yourself if it's too much work, but I'm happy to hear any suggestions if you come up with anything. Algorithms aren't my strong point, so I'll need some time to figure out further optimizations that can be done in terms of the calculation itself.

I do have a couple of ideas for things that I can implement in the meantime to address the issue of extensive loading times.

First, I can run the process asynchronously so that it doesn't stall the main loading process while it runs. It will usually finish by the time everything is loaded, but even if it doesn't, I doubt people would have a need for immediate access to a food's Diet values within the minute or so amount of time it would need to finish calculating (and that amount of time is already on the very high end of possible processing time).

Second, I can implement a config-enabled caching system. When enabled, the calculations after the first time will be cached into a file for use on future loads. The drawback is that the cache would prevent tag and recipe changes from propagating to Diet values properly until the file is deleted and regenerated, but if the modpack/environment is stable then that's less of a concern and it basically minimizes loading to a negligible amount on future loads.

I'll likely be rewriting traverseRecipes and the prelude that calls it, from what I've seen I believe I can make it massively faster & simpler. A few questions:
A few considerations regarding edge cases:
-How do you want to handle loops? I. e. cookies require beans which could require beans(Think crop-growing machines like the phytogenic insolator)
-How do you handle multiple ways of obtaining the item? e. g. bread could be made via one path that takes 3 wheat+water or an alternative path that only uses 1 wheat
If you're not sure that's fine I can figure out how the current implementation handles these cases.

If you want to take a crack at it, by all means. I'd be very interested in a faster and simpler solution. However, would your proposal come relatively quickly or should I implement some stop-gap solutions as outlined above to alleviate the issue in the meantime?

As for your questions:

1. Loops should be avoided as they aren't really relevant to the result. Knowing that cookies require beans is important because we need to know which food groups beans belong to, but knowing beans require beans doesn't help at all because we've already discovered it.
2. Only one way matters, so multiple recipes can be ignored if one is already found. However, it's important that this is done deterministically so that, for any particular set of recipes, the same recipe is always chosen for that particular item.

Thank you, it having to be deterministic makes a lot of sense. Is that why you sort the list by ID?

Yes, though I'm sure there are other ways to accomplish the same goal.

Any recommendations for food mods to test it with?

If the goal is to have a high number of recipes to test with, some mods that I remember having a lot are:
Crock Pot
Croptopia
Farmer's Delight
Pam's HarvestCraft 2 Food Extended (as well as the rest of the HarvestCraft series)
VanillaFoodPantry Mod
Vanilla Cookbook

Good news, I've nailed down a tentative new algorithm for the value generation in my development environment that, in my limited testing using E6E, lowers the processing time by more than 10 times the previous amount (in my case, from ~35 seconds down to ~2.5 seconds). In addition, the process will be done entirely parallel to the main server/world loading. All in all, the practical burdens on load times in even the most dense modpacks should be miniscule at worst.