-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Temporary turn off static graph restore. #8498
Merged
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
rainersigwald
approved these changes
Feb 24, 2023
jeffkl
reviewed
Feb 24, 2023
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
😭
rokonec
pushed a commit
to rokonec/msbuild
that referenced
this pull request
Mar 10, 2023
Our CI builds fails because of bug NuGet/Home#12373. It is fixed in NuGet/NuGet.Client#5010. We are waiting for it to flow to CI machines. Meanwhile this PR applies a workaround. Note: This PR needs to be reverted once it happens.
rokonec
pushed a commit
to rokonec/msbuild
that referenced
this pull request
Mar 14, 2023
Our CI builds fails because of bug NuGet/Home#12373. It is fixed in NuGet/NuGet.Client#5010. We are waiting for it to flow to CI machines. Meanwhile this PR applies a workaround. Note: This PR needs to be reverted once it happens.
rokonec
added a commit
that referenced
this pull request
Mar 14, 2023
…emetry instance (#8561) * BuildManager instances acquire its own BuildTelemetry instance (#8444) Fixes https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1708215 Context In VS there are multiple instances of BuildManager called asynchronously. For DTB and normal build and maybe other which I have not identified yet. Changes Made BuildManager instances acquire its own BuildTelemetry instance as oppose to sharing single BuildTelemetry instance in non thread safe manner. Testing Locally # Conflicts: # src/Build/BackEnd/Client/MSBuildClient.cs - resolved with minimal and safe approach * Bumping version * Turn off static graph restore. (#8498) Our CI builds fails because of bug NuGet/Home#12373. It is fixed in NuGet/NuGet.Client#5010. We are waiting for it to flow to CI machines. Meanwhile this PR applies a workaround. Note: This PR needs to be reverted once it happens. --------- Co-authored-by: AR-May <67507805+AR-May@users.noreply.github.com>
rokonec
added a commit
that referenced
this pull request
Mar 27, 2023
* Concurrency bug fix - BuildManager instances acquire its own BuildTelemetry instance (#8561) * BuildManager instances acquire its own BuildTelemetry instance (#8444) Fixes https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1708215 Context In VS there are multiple instances of BuildManager called asynchronously. For DTB and normal build and maybe other which I have not identified yet. Changes Made BuildManager instances acquire its own BuildTelemetry instance as oppose to sharing single BuildTelemetry instance in non thread safe manner. Testing Locally # Conflicts: # src/Build/BackEnd/Client/MSBuildClient.cs - resolved with minimal and safe approach * Bumping version * Turn off static graph restore. (#8498) Our CI builds fails because of bug NuGet/Home#12373. It is fixed in NuGet/NuGet.Client#5010. We are waiting for it to flow to CI machines. Meanwhile this PR applies a workaround. Note: This PR needs to be reverted once it happens. --------- Co-authored-by: AR-May <67507805+AR-May@users.noreply.github.com> * Use AutoResetEvent as oppose to ManualResetEventSlim (#8575) Summary Customer, mainly internal like XStore, with huge repos, using msbuild /graph /bl on powerful development and build computers, might experience 15x plus regression in evaluation time. It has been identified as performance bug in our logging event pub/sub mechanism. When ingest queue reaches its bound, at .net472 ManualResetEventSlim causes way too many thread.Yields flooding the system with thread context switches. This hypothesis has been verified by PerfMon perfcounter System.ContextSwitches. Alhougt counterintuitive, AutoResetEvent , ManualResetEvent or even SpinLocking produced better behavior and with those the issue no longer reproduce. Customer Impact In case of XStore it was about 7 minutes in build time. Regression? Yes, introduced in VS 17.4. Testing Manual validation by @rokonec and automated tests. Using local repro to verify changes has fixed it. Risk Low Note It effect only VS MSBuild.exe. In dotnet build ManualResetEventSlim works better. --------- Co-authored-by: Roman Konecny <rokonecn@microsoft.com> Co-authored-by: AR-May <67507805+AR-May@users.noreply.github.com>
/backport to vs17.2 |
1 similar comment
/backport to vs17.2 |
Started backporting to vs17.2: https://github.com/dotnet/msbuild/actions/runs/4790034849 |
Forgind
pushed a commit
that referenced
this pull request
Apr 26, 2023
Turn off static graph restore. (Backport of #8498 to vs17.2)
JanKrivanek
added a commit
that referenced
this pull request
Apr 26, 2023
commit 81da5a2 Author: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> Date: Wed Apr 26 10:17:54 2023 -0700 [vs17.2] Temporary turn off static graph restore. (#8697) Turn off static graph restore. (Backport of #8498 to vs17.2) commit 872ddd9 Merge: 94fcedf 6faa1d5 Author: Forgind <12969783+Forgind@users.noreply.github.com> Date: Mon Feb 13 07:30:47 2023 -0800 Merge pull request #8419 from Forgind/fix-temp-file-filtering-17.2 Fixes AB#1678521 Context #8049 broke the temp filtering logic by using the MSBuild-specific temp path instead of the true base temp path. This manifests as an overbuild of some C++ projects. Changes Made Reverted the change. Enabled relevant unit tests. Testing Existing unit tests and a C++ end-to-end repro. Notes The rest of FileTracker tests cannot be enabled without significant work (related to #649). commit 6faa1d5 Merge: 94fcedf 2fdde65 Author: Forgind <Forgind@users.noreply.github.com> Date: Tue Feb 7 14:56:15 2023 -0800 Merge branch 'vs17.0' of https://github.com/dotnet/msbuild into vs17.2 commit 2fdde65 Author: Forgind <12969783+Forgind@users.noreply.github.com> Date: Tue Feb 7 09:06:10 2023 -0800 Fix temp file filtering in FileTracker (#8352) (Copied from #8351) Fixes AB#1678521 Context #8049 broke the temp filtering logic by using the MSBuild-specific temp path instead of the true base temp path. This manifests as an overbuild of some C++ projects. Changes Made Reverted the change. Enabled relevant unit tests. Testing Existing unit tests and a C++ end-to-end repro. Notes The rest of FileTracker tests cannot be enabled without significant work (related to #649).
rainersigwald
added a commit
that referenced
this pull request
Jun 7, 2023
This reverts commit 7c4d75d.
YuliiaKovalova
pushed a commit
to YuliiaKovalova/msbuild
that referenced
this pull request
Jul 18, 2023
This reverts commit 7c4d75d.
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.
Our CI builds fails because of bug NuGet/Home#12373.
It is fixed in NuGet/NuGet.Client#5010.
We are waiting for it to flow to CI machines. Meanwhile this PR applies a workaround.
Note: This PR needs to be reverted once it happens.