-
Notifications
You must be signed in to change notification settings - Fork 189
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
Improve LocalModCard performance #1206
Conversation
Some manual performance testing with a profile that contains 282 mods. Numbers are in seconds and are averages from three rounds, except for the the built column, which was checked only once. The first three columns use the dev build by created by
‡ = modal opens up practically instantly Summary: the changes depend on earlier branches in this stack, which slow down the initial rendering a bit. As a tradeoff it significantly improves performance of some operations. Staring just the numbers can be a bit misleading though, since all use cases include the initial render, while someone disabling BepInEx and all the mods depending on it seems an unlikely scenario. On the other hand initial rendering is done only once, while user might e.g. open the modals multiple times in a session. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM 👍
5ba2cad
to
bbd7ea6
Compare
- Skip the whole process if the mod has no dependencies - Combine the methods to avoid looping over the same localModList and dependency list multiple times - Only loop over the localModList (which is the larger of arrays) once and return early if all dependencies are found - Stop appending dash to mod names, it's no longer needed since the new implementation doesn't use .startsWith() - Stop lowercasing the mod names since it doesn't seem to be needed. This is more about code clarity than performance.
41af04e
to
0c748a4
Compare
No description provided.