Relax StackGuard thresholds?

[majocha]

Current default StackGuard depths can result in tens of thousands thread switches during compilation and / or type checking, especially when CEs and resumable state machines are involved.

For example compiling IcedTasks.Tests.fsproj for net9.0:

caller	source	jumps
remapExprImpl	TypedTreeOps.fs:6008	2089
CheckExpr	TailCallChecks.fs:315	1382
exprF	TypedTreeOps.fs:7448	29661
CheckExpr	PostInferenceChecks.fs:1152	173
OptimizeExpr	Optimizer.fs:2343	23959

It seems this can add 10% or more to build time for projects with heavy CE use.

Taking IcedTasks.Tests as example, rising the relevant StackGuard depths makes the Optimizations phase go from 12s to 8s and the overall build time from 24s to 19s.

Most of the default depths are currently 50 or 100, I raised them x2 to test this and got zero thread switches during build.

[majocha]

OTOH #13084

[T-Gro]

There are in place to avoid SOs, most of them should have happened in the past and were capture by one of the many tests / stress tests. If there is place to change the thresholds while avoiding SOs (staying within the stack limit) on all platforms, then I am definitely for it.

I haven't seen anything similar to https://stackoverflow.com/a/42695614/1160340 done to asses the amount of stack taken/available per named-stackguard (e.g. calculate how much stack is gone after 10 stackguard controlled iterations). Very likely, the existing number are all guesstimates.

[edgarfgp]

There was a previous attempt #16754

[majocha]

I haven't seen anything similar to https://stackoverflow.com/a/42695614/1160340 done to asses the amount of stack taken/available per named-stackguard (e.g. calculate how much stack is gone after 10 stackguard controlled iterations). Very likely, the existing number are all guesstimates.

Shouldn't be hard to add this to current StackGuard stats, but there is no easy way to make it platform independent.

I wonder about EnsureSufficientExecutionStack

Can't we use it instead of arbitrary limits?

EDIT: It does seem to work.

[T-Gro]

EnsureSufficientExecutionStack communicates result by throwing an Exception.
If that SO is truly exceptional - this could be the way to go.

For common scenarios, I would be more inclined towards using EnsureSufficientExecutionStack for measurement and avoiding that exception throw.

On the other hand, the exception throw would be already at a time where we would need to delegate a new thread, so the costs amortizes well accounting-wise?

[majocha]

On the other hand, the exception throw would be already at a time where we would need to delegate a new thread, so the costs amortizes well accounting-wise?

Yes, I think it's worth it. With it I'm getting much less thread jumps building VisualFSharp. In the case of IcedTasks.Tests.fsproj (see above) there are now zero thread switches with nice compilation speed boost. I guess typechecking in the IDE would benefit also.

[T-Gro]

So we get less thread switches, but then also 1 exception per thread switch. Sounds like a good tradeoff.

Only if we knew about a place where guards happen a lot for most compilations anyway (are there such?), we might re-assess that.