
Hello Joachim, This was halfway known, but it sounds like we haven't solved it completely. The beginning of the sordid tale was when Cabal HEAD switched to using derived binary instances: https://ghc.haskell.org/trac/ghc/ticket/9583 SPJ fixed the infinite loop bug in the simplifier, but apparently the deriving binary generates a lot of code, meaning a lot of memory. https://ghc.haskell.org/trac/ghc/ticket/9630 hvr's fix was specifically to solve this problem. But it sounds like it didn't eliminate the regression entirely? If there's an unrelated regression, we should suss it out. It would be helpful if someone could revert just the deriving changes, and see if this reverts the compilation time. Edward Excerpts from Joachim Breitner's message of 2014-09-30 13:36:27 -0700:
Hi,
the attached graph shows a noticable increase in build time caused by
Update Cabal submodule & ghc-pkg to use new module re-export types author Edward Z. Yang
https://git.haskell.org/ghc.git/commit/4b648be19c75e6c6a8e6f9f93fa12c7a4176f... and only halfway mitigated by
Update `binary` submodule in an attempt to address #9630 author Herbert Valerio Riedel
https://git.haskell.org/ghc.git/commit/3ecca02516af5de803e4ff667c8c969c5bffb... I am not sure if the improvement is related to the regression, but in any case: Edward, was such an increase expected by you? If not, can you explain it? Can it be avoided?
Or maybe Cabal just became much larger... +38% in allocations when running haddock on it seems to confirm this.
Greetings, Joachim