-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
Comments
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. |
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. |
All the MSBuildNameIgnoreCaseComparer part of this bug has been removed in #2549. |
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.
In this customer's project: dotnet/project-system#2712, I'm seeing a non-trivial amount of contention in some very hot paths:
Can we look at doing some lock-free operations in these hot paths, especially the non-dataflow ones?
The text was updated successfully, but these errors were encountered: