Use caching to improve performance of large profiles #1151
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Forgot to implement the cache clearing when the package list is updated, so changed this to draft. |
When the local mod list is browsed vue seems to render the whole list again on some user actions. This causes three methods of the component to get called repeatedly: - getMissingDependencies, which uses modifiableModList property, which is based on the mod list stored in VueX store. modifiableModList is used by other parts of the component as well, so I thought better not touch it at this time since figuring out unintended side effects would be a lot of work - getThunderstoreModFromMod, which used the Thunderstore mod list stored in VueX, but now uses the list stored in the ThunderstorePackages. As far as I can tell both are updated in the Splash view and by the scheduled background process in UtilityMixin. Ergo this shouldn't break things, but this is the most significant functional change in this commit, and therefore most likely culprit should problems arise - isLatestVersion, which did and still does use ThunderstorePackages for its shenanigans So while this commit doesn't reduce the incessant function calls, it caches the results to a simple object to reduce required calculations. Effects were tested with a profile containing a mod pack with 109 mods. Completing the following tasks were timed (roughly and manually), with the accompanying results (original vs. cached): - Initial rendering of the local mod list when moving from profile selection view: 7.0s vs. 5.4s - Opening modal to disable a mod with two dependants: 4.4s vs. 1,2s - Closing the modal without disabling the mod: 4.4s vs. 1.2s - Opening modal to uninstall the same mod: 4.5s vs. 1.0s - Uninstalling the mod: 15.8s vs 6.0s (There might be further changes for optimizing the uninstall process, since it seems some stuff is done after each dependant is uninstalled, while it MIGHT be enough to do it just once in the end.) For a small profile with 3 mods there's no noticeable difference between the performance of the old and new implementation.
anttimaki
force-pushed
the
profile-performance
branch
from
a3c9d70
to
5f66820
Compare
|
Now clears cache when new package list is downloaded from the API. |
MythicManiac
approved these changes
Jan 22, 2024
Comment on lines
32
to
38
| const mod: ManifestV2 = new ManifestV2().fromReactive(vueMod); | ||
| const latestVersion: ThunderstoreVersion | void = ModBridge.getLatestVersion(mod, ThunderstorePackages.PACKAGES); | ||
| if (latestVersion instanceof ThunderstoreVersion) { | ||
| return mod.getVersionNumber() | ||
| .isEqualTo(latestVersion.getVersionNumber()) || mod.getVersionNumber().isNewerThan(latestVersion.getVersionNumber()); | ||
| return mod.getVersionNumber().isEqualOrNewerThan(latestVersion.getVersionNumber()); | ||
| } | ||
| return true; | ||
| } |
There was a problem hiding this comment.
Could this entire function be removed? Doesn't seem to be used outside of a single place now
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
When the local mod list is browsed vue seems to render the whole list again on some user actions. This causes three methods of the component to get called repeatedly:
So while this commit doesn't reduce the incessant function calls, it caches the results to a simple object to reduce required calculations. Effects were tested with a profile containing a mod pack with 109 mods. Completing the following tasks were timed (roughly and manually), with the accompanying results (original vs. cached):
(There might be further changes for optimizing the uninstall process, since it seems some stuff is done after each dependant is uninstalled, while it MIGHT be enough to do it just once in the end.)
For a small profile with 3 mods there's no noticeable difference between the performance of the old and new implementation.