F# 10 - Build time perf degradation for test projects in FSharpPlus

[T-Gro]

The following GH action testing FSharpPlus got stuck: https://github.com/fsprojects/FSharpPlus/actions/runs/19410283295/job/55530689891?pr=614

The testing step does a dotnet test build.proj -v n.

This has happened after updating the SDK to .NET 10.

Installed version is 10.0.100, it builds a PR which migrates the project over to .NET 10.
(must build this PR and not main for the exact repro - fsprojects/FSharpPlus#614 )

Reported by @gusty

[majocha]

I tried to build the pr:

gh pr checkout 614

dotnet test build.proj -v n

Eats lots of memory (this is the bug in type relations cache, fixed on main) and does not seem to finish. tests\FSharpPlus.Tests is the project that hangs.

with langversion 9 it does finish (unsuccessfully) after very long time:

dotnet build .\tests\FSharpPlus.Tests\  -bl --no-incremental
Restore complete (0.6s)
  FSharpPlus net8.0 succeeded (124.5s) → src\FSharpPlus\bin\Debug\net8.0\FSharpPlus.dll
  CSharpLib net8.0 succeeded (0.2s) → tests\CSharpLib\bin\Debug\net8.0\CSharpLib.dll
  FSharpPlus.TypeLevel net8.0 succeeded (11.5s) → src\FSharpPlus.TypeLevel\bin\Debug\net8.0\FSharpPlus.TypeLevel.dll
  FSharpPlus.Providers net8.0 succeeded (8.3s) → src\FSharpPlus.TypeLevel\bin\Debug\net8.0\FSharpPlus.Providers.dll
  FSharpPlus.Tests net8.0 failed with 4 error(s) (327.9s)
    E:\repos\FSharpPlus\tests\FSharpPlus.Tests\General.fs(1411,40): error FS0073: internal error: Undefined or unsolved type variable: '_?21158175
    E:\repos\FSharpPlus\tests\FSharpPlus.Tests\General.fs(1411,40): error FS0073: internal error: Undefined or unsolved type variable: '_?21158176
    E:\repos\FSharpPlus\tests\FSharpPlus.Tests\General.fs(1411,40): error FS0073: internal error: Undefined or unsolved type variable: '_?21158178
    E:\repos\FSharpPlus\tests\FSharpPlus.Tests\General.fs(1411,40): error FS0501: The member or object constructor 'Invoke' takes 1 argument(s) but is here given 2. The required signature is 'static member FSharpPlus.Control.Max.Invoke: source: ^Foldable<'T> -> 'T when (FSharpPlus.Control.Max or ^Foldable<'T>) : (static member Max: ^Foldable<'T> * FSharpPlus.Control.Max -> 'T) and 'T: comparison'.

Build failed with 4 error(s) in 473.2s

I notice that even with the latest main compiler, for FSharpPlus caching does not pay off and actually slows things down.
That's maybe an argument to provide a dedicated switch for it.

[gusty]

@majocha unfortunately there were regressions in F#9 that's why you have to use the branch of this PR

I think at least at ac945e9791cddaca92e754fedd946f9e91ef55e0 it was green on the CI.

It might be possible that some regressions are not captured by the lang version switch, the safest way is to use an MS docker image to test locally.

Regarding build time degradation, I also noticed. It took 30 mins in my computer to build the core library alone.
However, it's possible that the optimizations degraded the build time of the library but improved the compile time for the consumers. I think it's something worth to test.

CC: @wallymathieu

[T-Gro]

I notice that even with the latest main compiler, for FSharpPlus caching does not pay off and actually slows things down. That's maybe an argument to provide a dedicated switch for it.

I think we should have a switch, yes. Either more generalized <DisableFsharpFeature>..<> linked to LanguageFeatures set, or specific to the cache.

It still means people will have to know about, which is not optimal (bot hopefully affecting only a few). Is there a specific pattern which could be fast-detected and opt-out from the cache?

@gusty :
I think setting FSharpPlus to LangVersion=9 in Directory.Build.props is the best recommendation for now.

[majocha]

It still means people will have to know about, which is not optimal (bot hopefully affecting only a few). Is there a specific pattern which could be fast-detected and opt-out from the cache?

FSharpPlus.Tests here is a great example. During build it hits the cache freaking 50 million times:

| typeSubsumptionCache                     |    99.87% | 65658 |       0 | 52187893 |  65658 | 

but because the compiler never manages to solve the types, it has to regenerate the keys every time which ends up more expensive than the caching saves. So, ratio of unsolved types could be one heuristic. I can think of some optimizations here, too.

[T-Gro]

I would love if we can have a path of least surprises.
Heavy SRTP libs can set the flag when we tell them to, but regular apps would benefit from some automatic decision.

Maybe ratio of unsolved typars with constraints vs resolve type app? Since cache is mostly useful only for solved ttype_app

[wallymathieu]

Why doesn’t it cache failed solutions?