ActivePatterns: Compilation issues (memory and speed)

[Thorium]

I'm trying to compile a little simple F# file I made, using the latest released stable .NET.
Zip attached

ClassLibrary1.zip

Expected behaviour

Either compile or fail in a meaningful manner.
F# should be fast to compile a single file, right?

Actual behaviour

I have no idea what is going on.

Related information

Provide any related information (optional):

• Operating system: Windows 11
• .NET Runtime kind (.NET Core, .NET Framework, Mono): Net 9.0,.201
• Editing Tools (e.g. Visual Studio Version, Visual Studio): Dotnet.exe or VS 2022 Professional 17.13.5.

[Thorium]

This is somehow related to active-pattern usage:

match
| A
| B
| C
| D
...
| Y
| Z when (something) -> ... // out of memory

But if the when-conditions break the match often, (even with identical "something") then it works:

match
| A when (something) -> ...
| B when (something) -> ...
| C when (something) -> ...
| D when (something) -> ...
| E when (something) -> ...
| F when (something) -> ...
...
| Z when (something) -> ...

[T-Gro]

Bisecting tells me the issue (I assume it is an infinite loop, but could also be something too slow and I was not patient enough to see it finish) is within

// A = "x" && A = "x" ->  A = "x"
    let ``remove duplicate condition`` (e:Expression) =

function's body.
The code above it, despite also having big patterns (e.g. ~150 clauses for distribute_complement) compile fine.

[Thorium]

Yes. Although if you remove that code totally, and then remove the other duplicate intermediate "when"s, then it will fail as well:

The annoying thing here is that you'd expect the code to be more efficient when removing the "unnecessary" whens.

[T-Gro]

The presence of a when can disable certain optimizations due to having the possibility of a side effect.

This --times:files.csv output indeed tells that there is something in optimizations for this file.
Worth mentioning that even the typechecking and TAST->IL transformations (=IlxGen) are super slow considering a single-file project here.

(note that I have disabled all optional optimizations just to get the compilation done, there likely are other bottlenecks if the full optimizations would be running)

[Thorium]

Something like this maybe? https://sharplab.io/#v2:DYLgZgzgNALiCGEC2AfAsAKGAUxgAnwF48AlbCASwC9sBBAJ3vgE8AeAewCMArAPgAoAlJkw587AHbYAkhIAqAC2wBRCQBMheYpjy68SeDADGCgngDuFGAp16UeEAH48AZWYQY2JADoAwu2AcIxgKSQhvAHFsKXoKI28AGQoPVgB9Xl1bXXsnV3dPH39A7GDQiXComLjE5Jg0jLwsvBznNw8vPwCgkLDI6OxY+KSU9MyMPWaHVvyOou6yiv7BmpGGppa89sKukp7yvqqh2vqxiY22gs7i0t7KgerhutHG8bspzcu53YWD+6PV05vXIXWY7G77O7LR4nF5nd4g7bXPaLQ4rJ5rV7ZeEzRHzW5LB7HZ7rbFbK54iEE/7owFY4E48nffGo6HEzGTelkr7glF/NEwkmcz5g5G/KFEjFwoWgpE/SGEgGIAgAFgsSgkKs6AFcJEQ8AAGPAAWgyMGVJNSxoyEi1gREWFweEkyngJn86isZU02nZBmMpnwlmsgumXJFcqp/NGSrNauimv8Or1hpNKpDHxlFN54sVEBVcY1Zu1uq0BqtafZ5wZ3NF8upJxjqvM6oT7CTpZTpvNldJwtlzL5rIyjYLrfbxE7Falob7WbFCppI+b8aLiZLE/LZvTCMZPPn9ejedjy8LyuLyc33enGdxTMpLIleCXLdXbfXZdTW570tve7rUeHI8mxfM81wvT8ryBGdMzvbMFwbIDR1fccPy7bdq3DAcc0XRCTzHd9Jy/a8dxrCMH1zfM8OQgjL3QsN+3vQdH2fFdQLfcC0O/aDf1rSMhyfXCQPPDtaK4m9d148icMooSwJEiC6NnWD9wAgSZNY4SNwUntLVTG07QwURHWdAA3AZmAAMQoMz3TUT1JG9WE9D9EwzCDGwxJIzDGOwgVPIwhi4IPSUoPE0isPgtliICud/34py6W4iSyKYijj1k9j5M46L6NivjHwSjkkvCnzIpCxKwu8oLVMKqtcuUuKCsUmC/3ytLgI0uStOy0KvMClT4uaniUt8qLepihq2ppWrexayTUumobkoi4K1PSzrMu6qc3l061bWAe0gA===

[T-Gro]

There is definitely a missing reduction step to put those shared conditions together, which is also what might be slowing down the compilation's optimization phase.

It correctly unifies the type check / type cast as far as I can see, but it still multiplities the when clause contents instead of unifying it. Strange.