List.contains performance

Hi, we’ve found that List.contains x xs is slower than List.exists (fun y -> x = y) xs, details in my blog post: https://jindraivanek.hashnode.dev/curious-case-of-listcontains-performance

Summary:

• List.contains is ~2x - ~14x slower based on type in my benchmark
• slowness is due to LanguagePrimitives.HashCompare.GenericEqualityIntrinsic call
• benchmark repo is here: https://github.com/jindraivanek/Benchmarks-list-contains/blob/master/Benchmarks/Program.fs
• benchmark table here: https://github.com/jindraivanek/Benchmarks-list-contains/blob/master/Benchmarks/BenchmarkDotNet.Artifacts/results/ListBenchmarks.ListTests-report-github.md

Would you be in favor to change List.contains implementation to

    let inline contains value source =
        source |> tryFind (fun x -> value = x) |> Option.isSome

?

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

BenchmarkDotNet=v0.13.4, OS=Windows 10 (10.0.19045.3208)
12th Gen Intel Core i7-12800H, 1 CPU, 20 logical and 14 physical cores
.NET SDK=8.0.100-preview.6.23330.14
  [Host]     : .NET 7.0.9 (7.0.923.32018), X64 RyuJIT AVX2 DEBUG
  DefaultJob : .NET 7.0.9 (7.0.923.32018), X64 RyuJIT AVX2

[vzarytovskii]

@T-Gro Let’s just throw away the nan nonsense and consider them equal. https://github.com/fsharp/fslang-suggestions/issues/1280

As a separate item for future probably. Not part of this change.

[jindraivanek]

@T-Gro That’s great, thanks! Nice trick with isMatch, moving outside rec function.

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