discussion: impact of using exceptions on memory traffic to hold info in ConstraintSolver.ResolveOverloading

[smoothdeveloper]

Just sharing an experiment: I'm running memory profiling on building of FSharpPlus test project (https://github.com/fsprojects/FSharpPlus/tree/master/tests/FSharpPlus.Tests).

The project is less than 4k lines of F# code, but it relies heavily on overload resolution and is a good stress test for that code in the compiler.

You can see the code has nothing special, the snapshots compared here are with "tracking of allocations" enabled between a snapshot taken early after starting the compilation and 1h+ in running.

I was interested in calls to ArgsMustSubsumeOrConvert and ArgsMustSubsumeOrConvertInsideUndo and how they are allocating ErrorsFromAddingSubsumptionConstraint for each argument of each method call being checked.

fsharp/src/fsharp/ConstraintSolver.fs

Line 2414 in 0595fec

(ArgsEquivInsideUndo csenv cx.IsSome)

fsharp/src/fsharp/ConstraintSolver.fs

Line 2431 in 0595fec

(ArgsMustSubsumeOrConvertInsideUndo csenv ndeep newTrace cxsln cx.IsSome)

fsharp/src/fsharp/ConstraintSolver.fs

Line 2470 in 0595fec

(ArgsMustSubsumeOrConvertInsideUndo csenv ndeep newTrace cxsln cx.IsSome)

https://github.com/dotnet/fsharp/blob/master/src/fsharp/ConstraintSolver.fs#L2657

fsharp/src/fsharp/ConstraintSolver.fs

Line 192 in 0595fec

exception ErrorsFromAddingSubsumptionConstraint of tcGlobals: TcGlobals * displayEnv: DisplayEnv * TType * TType * exn * ContextInfo * range

ErrorsFromAddingSubsumptionConstraint being an exception (like many other types used in type checking), it carries significant weight in the base type, that is AFAIU not relevant for the purpose of carrying info, to eventually show error messages.

Notice that 500k of those exceptions are allocated for the purpose of resolving overloads, they are of course, very short lived, but I wonder if this doesn't have an impact in memory constrained scenarios like usage in tooling.

Is there any intuition about the impact of all the extra fields in System.Exception knowing that many of those objects are allocated during every method overload resolution?

To profile this, I've run debug version of fsc.exe compiled in this repository with this response file https://gist.github.com/smoothdeveloper/edbb90f8ea0cd9d6808d05fc528c375f

edit: after type checking completed, a total of 618250 ErrorsFromAddingSubsumptionConstraint have been instanciated / collected.

[cartermp]

In general the additional 500k would be negligible. I mean, yes in theory an additional 500k can tip something over the limit where VS would go OOM, but in practice this seems unlikely to do it. Many, many more things going on in the IDE allocate orders of magnitude more memory, such as the open declarations analyzer. It's likely that changing the current mechanism used in the compiler to track errors via exceptions is expensive work and 500k isn't the order of magnitude we'd like to see for something so invasive.

[cartermp]

Will close this out - 500k is quite small in the grand scheme of things. For example, just a quick trace from editing a few files in the compiler codebase (#9218 (comment)) showed over 200MB of tuple allocations in a 60s or so timespan.