-
Notifications
You must be signed in to change notification settings - Fork 3.2k
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
Perf bottleneck because of SortedDictionary in Annotatable.FindAnnotation #25488
Comments
Split off the (possible) correctness issue to #25489 (use ordinal comparison) |
In 6.0.0 we introduced the optimized runtime model and |
Great, have added verified-fixed to make sure. |
Profiling the repro application in #20135 shows that almost 30% of the model building time is spent doing SortedDictionary.TryGetValue inside Annotatable.FindAnnotation... We may still want to revisit this even if it no longer impacts runtime (and even if we have compiled models). (but confirm first that runtime isn't impacted) |
Since |
Done in d8e9f61 |
The following was reported offline by @feng-yuan (thanks!)
Found an expensive EF stack:
GetValueComparer is costing 139 k CPU samples, 6% in this hot stream, mostly due to SortedDictionary lookup in Annotable.FindAnnotation.
We know sorted dictionary is slower than dictionary because its lookup is O(Ln(N)), but there is something more to make the code slower, or even incorrect here.
SortedDictionary<string, Annotation> is allocated with default constructor. So the comparer is using String.Compare which is using current culture. Here is the evidence:
String.CompareTo is on the right. Zoom-in:
So lookup is now dependent on current thread culture.
At least, you need to change the code to :
If order is not important, Dictionary<string, Annotation> would be even faster and smaller.
The text was updated successfully, but these errors were encountered: