Skip to content
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

[automated] Merge branch 'vs17.4' => 'vs17.5' #8562

Merged
merged 3 commits into from
Mar 27, 2023

Conversation

dotnet-maestro-bot
Copy link
Contributor

I detected changes in the vs17.4 branch which have not been merged yet to vs17.5. I'm a robot and am configured to help you automatically keep vs17.5 up to date, so I've opened this PR.

This PR merges commits made on vs17.4 by the following committers:

Instructions for merging from UI

This PR will not be auto-merged. When pull request checks pass, complete this PR by creating a merge commit, not a squash or rebase commit.

merge button instructions

If this repo does not allow creating merge commits from the GitHub UI, use command line instructions.

Instructions for merging via command line

Run these commands to merge this pull request from the command line.

git fetch
git checkout vs17.4
git pull --ff-only
git checkout vs17.5
git pull --ff-only
git merge --no-ff vs17.4

# If there are merge conflicts, resolve them and then run git merge --continue to complete the merge
# Pushing the changes to the PR branch will re-trigger PR validation.
git push https://github.com/dotnet-maestro-bot/msbuild HEAD:merge/vs17.4-to-vs17.5
or if you are using SSH
git push git@github.com:dotnet-maestro-bot/msbuild HEAD:merge/vs17.4-to-vs17.5

After PR checks are complete push the branch

git push

Instructions for resolving conflicts

⚠️ If there are merge conflicts, you will need to resolve them manually before merging. You can do this using GitHub or using the command line.

Instructions for updating this pull request

Contributors to this repo have permission update this pull request by pushing to the branch 'merge/vs17.4-to-vs17.5'. This can be done to resolve conflicts or make other changes to this pull request before it is merged.

git checkout -b merge/vs17.4-to-vs17.5 vs17.5
git pull https://github.com/dotnet-maestro-bot/msbuild merge/vs17.4-to-vs17.5
(make changes)
git commit -m "Updated PR with my changes"
git push https://github.com/dotnet-maestro-bot/msbuild HEAD:merge/vs17.4-to-vs17.5
or if you are using SSH
git checkout -b merge/vs17.4-to-vs17.5 vs17.5
git pull git@github.com:dotnet-maestro-bot/msbuild merge/vs17.4-to-vs17.5
(make changes)
git commit -m "Updated PR with my changes"
git push git@github.com:dotnet-maestro-bot/msbuild HEAD:merge/vs17.4-to-vs17.5

Contact .NET Core Engineering if you have questions or issues.
Also, if this PR was generated incorrectly, help us fix it. See https://github.com/dotnet/arcade/blob/master/scripts/GitHubMergeBranches.ps1.

…emetry instance (dotnet#8561)

* BuildManager instances acquire its own BuildTelemetry instance (dotnet#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. (dotnet#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>
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.
@dotnet-maestro-bot
Copy link
Contributor Author

This pull request has been updated.

This PR merges commits made on vs17.4 by the following committers:

@rokonec rokonec merged commit 8b68842 into dotnet:vs17.5 Mar 27, 2023
@rainersigwald
Copy link
Member

Ah, sorry @rokonec I led you astray. We should always merge these PRs on GitHub; I was thinking of the insertion-to-VS PR in the VS repo when I said to squash (but didn't communicate that clearly).

I'll remerge

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants