Fix slow load/save of scenes with many instances of the same script #49570
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 my hypothesis and approach to fix #43156.
@reduz did c79be97 quite a long time ago to fix one of these: #756, #859, #914
There, some
changed
condition was removed so_update_exports()
would update every script placeholder instance regardless the script had changed or not. One effect I can confirm if the condition is re-added is that the property inspector won't show the exported variables anymore (however, I'm not sure if the removal fixes something else in addition, and that's why I've listed all the three potential issues that may be addressed by the change).However, that change also introduced the behavior that when the scene edit state is generated –which happens when saving or loading a scene–, every placeholder instance of a given script triggers the update of the exports of all the others that have been found so far, which may even happen several times because the same code is run for the whole inheritance chain.
This PR fixes that by making such updates conditional again, this way:
changed
is back), all the instances are updated, which is what was happening unconditionally and causing the slowness.Lastly, I think that C# was added when
change
had already been removed from the condition a long time ago, so it would be affected by the same bug. For that reason, I've applied the patch there as well.Disclaimer:
As I said above, this is based on my hypothesis about the bug, but it's hard to be sure. Also, testing to ensure all the aforementioned bugs (or any other, for that matter) aren't resurrected would be very difficult,
@akien-mga, being that the case, I'm not sure if this should get the Needs testing tag or, considering that specific testing for regressions is impractical or nearly impossible, just let users do it via alphas/betas.
Supersedes #47828.
Fixes #43156.