Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Several performance improvements #35

Merged
merged 6 commits into from
Mar 9, 2023
Merged

Conversation

embeddedt
Copy link
Contributor

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:
    image
    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:

before_au

Profiler screenshot after this PR:

after_au

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
Copy link
Member

LLytho commented Mar 9, 2023

Hey,

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

@LLytho LLytho requested review from rlnt and LLytho March 9, 2023 13:26
Copy link
Member

@rlnt rlnt left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice performance improvement, thanks for the PR! Two minor things I'd like to change here.

  1. The duplication config is loaded inside the runtime which we keep alive for other mods to use. The cache needs to be cleared after the unification process.
  2. Rename recipeTypeIgnoreCache to ignoredRecipeTypesCache (I will probably rename a lot of stuff in a new major version because of all the inconsistencies in general).

@rlnt rlnt merged commit 96e9621 into AlmostReliable:1.18 Mar 9, 2023
rlnt added a commit that referenced this pull request Mar 10, 2023
Co-authored-by: LLytho <main@lytho.dev>
Co-authored-by: Relentless <relentless@rlnt.dev>
rlnt added a commit that referenced this pull request Mar 10, 2023
Co-authored-by: LLytho <main@lytho.dev>
Co-authored-by: Relentless <relentless@rlnt.dev>
@rlnt rlnt mentioned this pull request Aug 22, 2024
5 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants