NGEN Microsoft.DotNet.MSBuildSdkResolver.dll and its dependencies #17732
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
|
Can you post a sample of the generated output (running |
joeloff
reviewed
Nov 8, 2023
joeloff
reviewed
Nov 8, 2023
ladipro
commented
Nov 8, 2023
joeloff
approved these changes
Nov 8, 2023
|
/backport to release/8.0.2xx |
|
Started backporting to release/8.0.2xx: https://github.com/dotnet/installer/actions/runs/6816949082 |
|
@ladipro an error occurred while backporting to release/8.0.2xx, please check the run log for details! Error: @ladipro is not a repo collaborator, backporting is not allowed. If you're a collaborator please make sure your dotnet team membership visibility is set to Public on https://github.com/orgs/dotnet/people?query=ladipro |
|
/backport to release/8.0.2xx |
|
Started backporting to release/8.0.2xx: https://github.com/dotnet/installer/actions/runs/6816962545 |
ladipro
pushed a commit
that referenced
this pull request
Nov 14, 2023
…s dependencies (#17750) Backport of #17732 to release/8.0.2xx MSBuild.exe currently spends a significant amount of time JITting `Microsoft.DotNet.MSBuildSdkResolver` and its dependencies, see dotnet/msbuild#9303 for details. This PR makes Visual Studio installer add these assemblies to the NGEN queue, which is a necessary condition for eliminating JITting. Just like `Microsoft.Build.*` assemblies, we need to NGEN these with two configurations: vsn.exe so it works in the devenv process, and MSBuild.exe so it works in MSBuild satellite processes.
ladipro
added a commit
to dotnet/msbuild
that referenced
this pull request
Dec 13, 2023
…SBuild.exe only) (#9439) Fixes #9303 ### Context After a new version of `VS.Redist.Common.Net.Core.SDK.MSBuildExtensions` is inserted into VS, a native image for `Microsoft.DotNet.MSBuildSdkResolver` will be generated, both for devenv.exe and MSBuild.exe (see dotnet/installer#17732). We currently load SDK resolvers using `Assembly.LoadFrom` on .NET Framework, which disqualifies it from using native images even if they existed. This PR makes us use the native image. ### Changes Made Added a code path to use `Assembly.Load` to load resolver assemblies. The call is made such that if the assembly cannot be found by simple name, it falls back to loading by path into the load-from context, just like today. The new code path is enabled only for `Microsoft.DotNet.MSBuildSdkResolver` under a change-wave check. ### Testing Experimental insertions. ### Notes Using `qualifyAssembly` in the app config has the advantage of keeping everything _field-configurable_, i.e. in the unlikely case that a custom build environment will ship with a different version of the resolver, it will be possible to compensate for that by tweaking the config file. The disadvantage is that the same `qualifyAssembly` will need to be added to devenv.exe.config because .pkgdef doesn't support this kind of entry, to my best knowledge. It should be a one-time change, though, because [we have frozen the version of `Microsoft.DotNet.MSBuildSdkResolver` to 8.0.100.0](dotnet/sdk#36733).
ladipro
added a commit
that referenced
this pull request
Apr 12, 2024
…es" for devenv only (#19399) Fixes: [AB#2014670](https://devdiv.visualstudio.com/DevDiv/_workitems/edit/2014670) ### Description A change was made in 8.0.2xx to register MSBuildSdkResolver for NGEN (#17732), against both devenv.exe and MSBuild.exe. Later a bug was found in the way MSBuild.exe loads the resolver so the change was reverted in 8.0.3xx (#19112). However, because the change had a measurable positive perf effect, the revert was effectively a regression for devenv.exe and got flagged so by PerfDDRITs. This PR is a re-do of the original change, only this time with MSBuild.exe omitted, i.e. we're NGENing the resolver only for the default architecture of devenv.exe. ### Customer Impact Startup perf regression, about 5% more methods JITted in scenarios measured by Visual Studio PerfDDRITs. ### Regression Yes, perf regression in VS 17.10. ### Risk Low
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.
MSBuild.exe currently spends a significant amount of time JITting
Microsoft.DotNet.MSBuildSdkResolverand its dependencies, see dotnet/msbuild#9303 for details.This PR makes Visual Studio installer add these assemblies to the NGEN queue, which is a necessary condition for eliminating JITting. Just like
Microsoft.Build.*assemblies, we need to NGEN these with two configurations: vsn.exe so it works in the devenv process, and MSBuild.exe so it works in MSBuild satellite processes.cc @joeloff @marcpopMSFT