Build time regressions

[Edward Z. Yang]

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 <ezyang at cs.stanford.edu>
> https://git.haskell.org/ghc.git/commit/4b648be19c75e6c6a8e6f9f93fa12c7a4176f0ae
> 
> and only halfway mitigated by
> 
> Update `binary` submodule in an attempt to address #9630
> author    Herbert Valerio Riedel <hvr at gnu.org>
> https://git.haskell.org/ghc.git/commit/3ecca02516af5de803e4ff667c8c969c5bffb35f
> 
> 
> 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
>