-
Notifications
You must be signed in to change notification settings - Fork 4.7k
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
Faster optimized frozen dictionary creation (1/n) #87510
Conversation
…iterate over it rather than the dictionary to get min and max lengths (1-2% gain)
…e know that at least 5% is bad (13-14% gain)
…n, 12% allocations reduction)
Tagging subscribers to this area: @dotnet/area-system-collections Issue DetailsBenchmarkDotNet=v0.13.2.2052-nightly, OS=Windows 11 (10.0.22621.1702)
AMD Ryzen Threadripper PRO 3945WX 12-Cores, 1 CPU, 24 logical and 12 physical cores
.NET SDK=8.0.100-preview.4.23259.14
[Host] : .NET 8.0.0 (8.0.23.25905), X64 RyuJIT AVX2
LaunchCount=3 MaxIterationCount=20 MemoryRandomization=True
|
Do you mean at most 5% is bad? Otherwise you could simply nop everything and 100% is bad, which is at least 5% :) |
The wording is correct. For a given capacity, once we've seen at least 5% of the entries conflict, we know we can't get to > 95% not conflicting, so we can give up on that capacity and try with the next. We can't give up until we've seen at least 5% conflict, and if we never see 5% conflict, then that capacity is good to go and we can use it. |
Thank you for the explanation. |
} | ||
|
||
private sealed class RightJustifiedCaseInsensitiveSubstringComparer : SubstringComparer | ||
private sealed class JustifiedCaseInsensitiveSubstringComparer : SubstringComparer |
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.
I'm happy to hear it's helpful, and the fewer the types the better, but I'm a little surprised this makes a positive impact on throughput, since it's adding more work on every comparison. What's the logic for why it makes things faster?
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.
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.
Is that true just in the example you're profiling or generally? The HashSet will happen once regardless of how many retries are needed.
{ | ||
set.Clear(); | ||
|
||
// SufficientUniquenessFactor of 95% is good enough. |
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.
This constant was deleted.
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.
I was too lazy/tired to turn the const name into three separate words. If you don't mind I am going to do that in next PR.
The failure is unrelated: #87505, merging |
@adamsitnik Can you point me to how to generate the benchmarking analysis? I'm looking into tweaking this a tiny bit more... |
Of course! This doc describes how to run benchmarks against a local build of dotnet/runtime: To get a trace file you can use the EtwProfiler Here is a short introduction to PerfView. If you are already familiar with PerfView then the generation of the profile diffs is described here BTW automating this diff is on my TODO list, I've already made the first step and implemented the dotnet/BenchmarkDotNet#2116
I am working on it right now, I expect to introduce changes to |
For this particular benchmark, the initial gap between creating the non-optimized (4 us) and optimized (89.4 us) was 85.4 us, now it's 69.2 us.