Reduce number of typeEquiv checks

[forki]

No description provided.

[En3Tho]

Do we have some sort of benchmark suite to see if these changes are helpful? I'm planning to try finding opportunities for optimizations too and I wonder if I find one, I can be assured stuff I code really helps

[cartermp]

The closes thing we have is CompilerServiceBenchmarks: https://github.com/dotnet/fsharp/blob/main/tests/benchmarks/CompilerServiceBenchmarks/Program.fs

We use benchmarkdotnet to experiment against a few different scenarios. It may need to be updated again now that some files have been rearranged.

If the benchmark doesn't yield anything meaningful then that's fine though. Sometimes a single change is marginal but when you combine it with 3-4 other marginal changes it's no longer marginal. So long as it's obvious that there is less work being done in the code then we'd be inclined to take it.

That said, the more evidence, the better!

[jonsequitur]

We've started on building up a benchmark suite here: dotnet/performance#1546.

Some discussion might be helpful here to make sure that we're designing benchmarks that will be useful for historical comparison over time as code is refactored.

[smoothdeveloper]

@jonsequitur I've reported a non-fruitive exploration in #8260 about experience of compiling FSharpPlus library unit tests.

The unit test codebase is arguably not representative of general F# codebase but it provides a very good test ground for overload resolution complexity and would very likely highlight performance regression in that logic.

I don't know for sure if the F# compiler team sees that as salliant but it felt to me we should take a snapshot of that codebase and use it as a benchmark.

If you feel it may have relevance for dotnet/performance#1546 I'll pay a closer look at that repository.

[KevinRansom]

Thanks for this.