[ fix ] Exponentially reduce memory consumption for elab scripts running

[buzden]

It's been noticed for a long time that memory consumption of the compiler executing elaborator scripts somewhat exponential on the reached depth of monadic bindings in the Elab monad. At the same time, it's been noticed that code like act1 *> act2 <* act3 uses much more memory comparing to the code do {act1; r <- act2; act3; pure r} when it is somewhere deep inside the script. My guess is that this is because of a closures preserving problem, similar to runtime problems of closure allocation.

Since both map and <*> were implemented through Bind in the Elab monad, I thought that running them in Core is much more efficient (because Core is effectively a glamourous IO, which is run optimised, with no cost for bindings). I tried this, but I didn't suspect how efficient this would be! My guess is that reduction of binds-depth severely reduces unneeded job of closures preserving in the evaluator.

Currently, one of my big elaborator scripts, which runs on the current main 3 hours 17 minutes taking 16.5 Gb of memory, runs just 2 hours 24 minutes using 10 Gb with this patch (both runs were on the same machine using the patched GC from Edwin). More impressively, another elaborator script that used more than 360 Gb of memory unabling to finish due to out of memory error, successfully finishes using just 10 Gb of memory with the change from this PR.

Those test are large and use a lot of dependencies, and it's really hard to make a small test out of them (and anyway, those cases run for several hours). I didn't manage to make a small test that exploits the problem being fixed.

In the implementation in managing newly added Map and Ap I used applyToStack function that is used in the management of the Bind constructor to apply arbitrary NF to an abribtrary closure. Unlike the Bind case, I used the weakest EvalOpts in order to not to reduce expressions too much (in fact, to preserve the status quo behaviour of produced expressions). I extended one exitsting test to make sure behaviour preserves in a different case too.

[gallais]

Impressive work!

[andrevidela]

My guess is that this is because of a closures preserving problem, similar to runtime problems of closure allocation.

implicit captures are evil for performance, definitely something we need to keep an eye on.