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

Non-trivial amount of lock contention #2429

Open
davkean opened this issue Aug 15, 2017 · 3 comments · Fixed by #2549
Open

Non-trivial amount of lock contention #2429

davkean opened this issue Aug 15, 2017 · 3 comments · Fixed by #2549
Labels
performance Performance-Scenario-General This issue affects performance in general. Priority:2 Work that is important, but not critical for the release triaged

Comments

@davkean
Copy link
Member

davkean commented Aug 15, 2017

In this customer's project: dotnet/project-system#2712, I'm seeing a non-trivial amount of contention in some very hot paths:

image

Can we look at doing some lock-free operations in these hot paths, especially the non-dataflow ones?

@davkean
Copy link
Member Author

davkean commented Aug 15, 2017

Make note, this isn't the time that was a thread was delayed - this is the time that Monitor.Enter was actually being executed by the CPU. ie There's so much contention here - that the overhead of the Monitor.Enter call itself is showing up on the radar.

@AndyGerlicher AndyGerlicher added this to the MSBuild 15 "foundation update" 2 milestone Aug 15, 2017
@davkean
Copy link
Member Author

davkean commented Sep 22, 2017

I do wonder if there is no contention here - but just the very act of calling into Moniter.Lock is just showing up on the radar.

@davkean
Copy link
Member Author

davkean commented Sep 27, 2017

All the MSBuildNameIgnoreCaseComparer part of this bug has been removed in #2549.

@davkean davkean reopened this Oct 2, 2017
radical pushed a commit to mono/msbuild that referenced this issue Oct 25, 2017
Fixes: dotnet#2434
Partially fixes: dotnet#2429

This change converts MSBuildNameIgnoreCaseComparer to a stateless comparer by implementing IConstrainedEqualityComparer, this avoids:

1. Creating a new comparer for every collection (saves ~1% of allocations)
2. Locking within Equals/GetHashCode (saves ~0.2% of allocations)

This saves approx 300ms running a design time build over the project called out in dotnet/project-system#2789.
@panopticoncentral panopticoncentral added the Performance-Scenario-General This issue affects performance in general. label Mar 28, 2020
@panopticoncentral panopticoncentral removed this from the MSBuild 15.6 milestone May 21, 2020
@panopticoncentral panopticoncentral added the Priority:2 Work that is important, but not critical for the release label Mar 23, 2021
@AR-May AR-May added the triaged label Feb 21, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
performance Performance-Scenario-General This issue affects performance in general. Priority:2 Work that is important, but not critical for the release triaged
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants