-
Notifications
You must be signed in to change notification settings - Fork 783
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
List.contains performance #15720
Comments
This would be a change in behaviour (not using generic equality anymore), thus a potentially breaking change. Needs to be investigated first, whether it behaves differently on any paths/different types, especially around tuples and types which have NaNs. |
I was expecially afraid of the behavior around In the end, I think this is failed inlining for the inner contains defined in the You can see in the This proposal makes sense to me - at least in the objective of making type specialization possible. |
The behavior stays the same, the |
@T-Gro That's great, thanks! Nice trick with I added it to benchmarks, performance looks good, best of all variants: https://github.com/jindraivanek/Benchmarks-list-contains/blob/master/Benchmarks/BenchmarkDotNet.Artifacts/results/ListBenchmarks.ListTests-report-github.md |
@T-Gro Let's just throw away the |
As a separate item for future probably. Not part of this change. |
Hi,
we've found that
List.contains x xs
is slower thanList.exists (fun y -> x = y) xs
, details in my blog post: https://jindraivanek.hashnode.dev/curious-case-of-listcontains-performanceSummary:
List.contains
is ~2x - ~14x slower based on type in my benchmarkLanguagePrimitives.HashCompare.GenericEqualityIntrinsic
callWould you be in favor to change
List.contains
implementation to?
Which turns out fastest from variants I tried. (In benchmark it is
List.containsTryFind
).I can extend benchmarks with more cases if needed.
I can make PR for this.
--
Note:
Benchmarks was done on
The text was updated successfully, but these errors were encountered: