Closed Boarders closed 4 years ago
The technique described above, while valuable, does not work on an executable as large as ours. It is useful for finding the first "space leak" bottleneck, but it is impossible to find problem "space leaks" past the first bottleneck. If the first bottleneck is not resolvable all others cannot be resolved with this technique.
Since our executable has a lot of dynamic allocation during the unification phase, the program cannot run in constant space past that point and any "space leaks" behind that point are masked by the unification phase when using this identification technique.
Closing as generally ineffective for our executable, unfortunately...
Not that this should be re-opened but (for future spelunkers) there is now a much, much better way to do this by using the nothunks package which has an introductory blog post here: https://www.well-typed.com/blog/2020/09/nothunks/
We should use the method described here to try to find any space leaks in our code.