Several performance improvements

[embeddedt]

Proposed Changes

This PR implements a number of optimizations designed to reduce the time spent running recipe transformations. This was done by carefully profiling a world load during Enigmatica 8 and then targeting the obvious bottlenecks. I have summarized the changes I made below.

• DuplicationConfig.shouldIgnoreRecipe has been optimized to avoid matching regexes as much as possible. In particular, whether or not a given recipe type ID is ignored is now cached. This saves a regex match for almost all recipes, as many of them will share the same type.
• In the same method, use of streams was replaced with standard for loops. This is to help reduce allocations and needless overhead since this code is run on every single recipe.

As a result of the above optimizations, this method is now about 4 times faster (which can be seen in the profiler results). I believe 2 seconds is enough of a difference that it's not just caused by Java's random speed variation between runs.

Most of the remaining time is spent within handleDuplicate, which essentially boils down to calling JsonCompare.matches. Unfortunately, checking two JSON objects for equality is a rather inefficient process in general, as key retrieval is O(log(n)) in tree maps. Nonetheless I was able to make a couple changes that reduced running time by about 40%.

• I removed the original logic that first looped over the key sets and checked whether the fields were ignored. This logic added quite a bit of overhead as can be seen in this profiler excerpt: Instead the logic was replaced with a simpler for loop that loops over each entry of one of the JSON objects, skips any keys that should be ignored, and attempts to retrieve the same key from the other object. In particular, this eliminates the need to call get on one of the objects entirely, as we can simply iterate over its entries and be given both a key and value at the same time.

Unfortunately this method is still bottlenecked by the JsonObject.get call. Further improvements are probably not possible without a cleverer solution that reduces the number of recipes being compared.

Lastly, I added a timer to RecipeTransformer.transformRecipes in order to see how long the process takes even when the profiler is not running.

I would appreciate if you could give these changes a try to verify that they don't only increase performance on ancient hardware. Let me know if you have any questions/feedback.

Additional Context

Profiler screenshot from latest 1.18 version:

Profiler screenshot after this PR:

I believe the time increase in unifyRecipes was simply an artifact of garbage collection/some other stall (I have very few CPU cores), and in any case the total runtime is clearly shorter.

[LLytho]

Hey,

thanks for the PR. I will take a deeper look later.