3 ms·

It sounds like this boils down to a codegen problem/bug with == / <>, mm? I recall a similar problem doing comparisons on some value types, perhaps it was DateT

It sounds like this boils down to a codegen problem/bug with == / <>, mm? I recall a similar problem doing comparisons on some value types, perhaps it was DateTime (IIRC, this was before VS2010). The fix was to add another case to the operator to make it take the fast path (do a direct call to the compare method vs some crazy generic path). Rather than make the code more verbose to hack around compiler limitations, fix the compiler? Though: if x == null then ... else ... is about the same as: match x with null -> ... | _ -> ... That said, null checking was never a perf area nor anything I've really had to deal much with in years of working with F#.

latkin 11y ago
The "crazy generic path" is still the default, but in F# 4.0 now there is a module `NonStructuralComparison` which can be opened, shadowing all of the generic operators with fast non-generic guys. See [this](http://blogs.msdn.com/b/dotnet/archive/2015/04/29/rounding-out-visual-f-4-0-in-vs-2015-rc.aspx http://blogs.msdn.com/b/dotnet/archive/2015/04/29/rounding-o...) blog, search for "non-structural comparison operators".
- MichaelGG 11y ago
  When I get to a PC I'll try it out. But basically instead of using IComparable directly (so you'd just have a single function call), it used to do something far more complicated first, but still end up calling the same compare function. For equality I'd expect it to inline a check for null before calling the full equality check. Then a later optimization pass or the JIT could fix it up to be just the null check.