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)
adamsitnik
added
area-System.Collections
tenet-performance
|
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.
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.
it's adding more work on every comparison
That is true, but it's less work compared to creating a new HashSet<string>(keys.Length)
There was a problem hiding this comment.
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.
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 |
ghost
locked as resolved and limited conversation to collaborators
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.