Lazily load the settings UI DLL #15628
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
Due to an implementation detail in the Xaml compiler--which wants to ensure that all metadata providers on an App are available immediately--we were eagerly loading the settings UI DLL and all of its dependencies, even in sessions where the user was not going to open Settings. By turning off eager provider generation and handling it ourselves, we get to control exactly when the settings UI is loaded. This required some gentle poking-through of the barrier between App and Page, but it is almost certainly worth it. Turning on the Xaml code generation flag to not generate providers automatically adds an `AddProvider` member to the internal interface for the autogenerated XamlMetadataProvider. We needed to switch to using the internal interface rather than the projected type in our custom App base class to get at it. Providers that App/Page use must be initialized by the time we start the WindowsXamlManager, so we load Control and Controls (ha) eagerly and early.
carlos-zamora
approved these changes
Jun 28, 2023
DHowett
added a commit
that referenced
this pull request
Jun 29, 2023
When we moved the settings UI to lazy initialization in #15628, we broke PGO. Apparently, we were PGOing the tiny part of Settings that was being loaded on every launch (e.g. the XAML metadata provider 🤦) Let's actually PGO launching the settings.
DHowett
added a commit
that referenced
this pull request
Jun 29, 2023
When we moved the settings UI to lazy initialization in #15628, we broke PGO. Apparently, we were PGOing the tiny part of Settings that was being loaded on every launch (e.g. the XAML metadata provider 🤦) Let's actually PGO launching the settings.
DHowett
added a commit
that referenced
this pull request
Jul 27, 2023
Due to an implementation detail in the Xaml compiler--which wants to ensure that all metadata providers on an App are available immediately--we were eagerly loading the settings UI DLL and all of its dependencies, even in sessions where the user was not going to open Settings. By turning off eager provider generation and handling it ourselves, we get to control exactly when the settings UI is loaded. This required some gentle poking-through of the barrier between App and Page, but it is almost certainly worth it. Turning on the Xaml code generation flag to not generate providers automatically adds an `AddProvider` member to the internal interface for the autogenerated XamlMetadataProvider. We needed to switch to using the internal interface rather than the projected type in our custom App base class to get at it. Providers that App/Page use must be initialized by the time we start the WindowsXamlManager, so we load Control and Controls (ha) eagerly and early. It looks like it may save 400ms of CPU time (?) on startup. (cherry picked from commit 0f41851) Service-Card-Id: 90012538 Service-Version: 1.17
DHowett
added a commit
that referenced
this pull request
Jul 27, 2023
Due to an implementation detail in the Xaml compiler--which wants to ensure that all metadata providers on an App are available immediately--we were eagerly loading the settings UI DLL and all of its dependencies, even in sessions where the user was not going to open Settings. By turning off eager provider generation and handling it ourselves, we get to control exactly when the settings UI is loaded. This required some gentle poking-through of the barrier between App and Page, but it is almost certainly worth it. Turning on the Xaml code generation flag to not generate providers automatically adds an `AddProvider` member to the internal interface for the autogenerated XamlMetadataProvider. We needed to switch to using the internal interface rather than the projected type in our custom App base class to get at it. Providers that App/Page use must be initialized by the time we start the WindowsXamlManager, so we load Control and Controls (ha) eagerly and early. It looks like it may save 400ms of CPU time (?) on startup. (cherry picked from commit 0f41851) Service-Card-Id: 90012539 Service-Version: 1.18
DHowett
added a commit
that referenced
this pull request
Aug 14, 2023
When we moved the settings UI to lazy initialization in #15628, we broke PGO. Apparently, we were PGOing the tiny part of Settings that was being loaded on every launch (e.g. the XAML metadata provider 🤦) Let's actually PGO launching the settings. (cherry picked from commit 80f2776) Service-Card-Id: 90213941 Service-Version: 1.18
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.
Due to an implementation detail in the Xaml compiler--which wants to ensure that all metadata providers on an App are available immediately--we were eagerly loading the settings UI DLL and all of its dependencies, even in sessions where the user was not going to open Settings.
By turning off eager provider generation and handling it ourselves, we get to control exactly when the settings UI is loaded.
This required some gentle poking-through of the barrier between App and Page, but it is almost certainly worth it.
Turning on the Xaml code generation flag to not generate providers automatically adds an
AddProvidermember to the internal interface for the autogenerated XamlMetadataProvider. We needed to switch to using the internal interface rather than the projected type in our custom App base class to get at it.Providers that App/Page use must be initialized by the time we start the WindowsXamlManager, so we load Control and Controls (ha) eagerly and early.
It looks like it may save 400ms of CPU time (?) on startup.