Improve performance when uninstalling multiple mods at once #1155
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
There's three methods that control how mods are uninstalled: uninstallModRequireConfirmation, which calls performUninstallMod directly if the mod has no dependants, and uninstallMod if the mod has dependencies. uninstallMod in turn calls performUninstallMod for the mod and all the dependants separately. This commit does the following changes: - By default, performUninstallMod now calls updateModListAfterChange helper, which differs from the original implementation in that it also calls filterModList method - Since uninstallModRequireConfirmation calls performUninstallMod, it no longer needs to call filterModList directly - performUninstallMod also accepts a new boolean parameter which can be used to prevent it from calling updateModListAfterChange - uninstallMod uses the said parameter to prevent the updateModListAfterChange getting called after each individual mod is uninstalled. It calls updateModListAfterChange itself directly in the end As far as I can tell this has no ill effects to the end result, i.e. the profile files that remain on the disk appear to be identical. The only downside I'm aware of is that the modal that shows the list of mods no longer gets updated during the process, so it might appear to the user that nothing happens. The benefit is that the process takes significantly less time when uninstalling a mod with lots of dependants. Prior to changes uninstalling BepInEx from a profile that contained 109 mods took 147 seconds, while after the changes it "only" takes 24 seconds.
This works as an indicator to the user that something is happening in case the uninstallation of multiple mods takes a bit longer.
|
If this is seen as good idea, similar optimizations can be done to disabling/enabling mods. |
|
Screenshot showing the disabled button and the indicator that shows which mod is currently being uninstalled. |
Comment on lines
449
to
482
| async uninstallMod(vueMod: any) { | ||
| let mod: ManifestV2 = new ManifestV2().fromReactive(vueMod); | ||
| try { | ||
| for (const dependant of Dependants.getDependantList(mod, this.modifiableModList)) { | ||
| const result = await this.performUninstallMod(dependant); | ||
| this.modBeingUninstalled = dependant.getName(); | ||
| const result = await this.performUninstallMod(dependant, false); | ||
| if (result instanceof R2Error) { | ||
| this.$emit('error', result); | ||
| this.modBeingUninstalled = null; | ||
| return; | ||
| } | ||
| } | ||
| const result = await this.performUninstallMod(mod); | ||
| this.modBeingUninstalled = mod.getName(); | ||
| const result = await this.performUninstallMod(mod, false); | ||
| if (result instanceof R2Error) { | ||
| this.$emit('error', result); | ||
| this.modBeingUninstalled = null; | ||
| return; | ||
| } | ||
| } catch (e) { | ||
| // Failed to uninstall mod. | ||
| const err: Error = e as Error; | ||
| this.$emit('error', err); | ||
| this.modBeingUninstalled = null; | ||
| LoggerProvider.instance.Log(LogSeverity.ACTION_STOPPED, `${err.name}\n-> ${err.message}`); | ||
| } | ||
| this.selectedManifestMod = null; | ||
| this.modBeingUninstalled = null; | ||
| const result: ManifestV2[] | R2Error = await ProfileModList.getModList(this.contextProfile!); | ||
| if (result instanceof R2Error) { | ||
| this.$emit('error', result); | ||
| return; | ||
| } | ||
| await this.$store.dispatch("updateModList", result); | ||
| const err = await ConflictManagementProvider.instance.resolveConflicts(result, this.contextProfile!); | ||
| if (err instanceof R2Error) { | ||
| this.$emit('error', err); | ||
| } | ||
| this.filterModList(); | ||
| await this.updateModListAfterChange(result); |
There was a problem hiding this comment.
Looks like there are a handful of code paths here which could in theory apply changes without refreshing the mod list, would it make sense to always refresh it before returning?
I'll push that change on top of this before merging since it seems a bit less prone to state management bugs that way.
Make sure the profile mod list is refreshed with the latest information even if the uninstall logic exits midway.
MythicManiac
approved these changes
Jan 22, 2024
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.
This is probably best reviewed commit by commit.