Fwd: Is anything being done to remedy the soul crushing compile times of GHC?

[Evan Laforge]

On Wed, Feb 17, 2016 at 4:38 AM, Ben Gamari <ben at smart-cactus.org> wrote:
> Multiple modules aren't a problem. It is dependencies on Hackage
> packages that complicate matters.

I guess the problem is when ghc breaks a bunch of hackage packages,
you can't build with it anymore until those packages are updated,
which won't happen until after the release?

>From a certain point of view, this could be motivation to either break
fewer things, or to patch breaking dependents as soon as the breaking
patch goes into ghc.  Which doesn't sound so bad in theory.  Of course
someone would need to spend time doing boring maintenance, but it
seems that will be required regardless.  And ultimately someone has to
do it eventually.

Of course, said person's boring time might be better spent directly
addressing known performance problems.

My impression from the reddit thread is that three things are going on:

1 - cabal has quite a bit of startup overhead
2 - ghc takes a long time on certain inputs, e.g. long list literals.
There are probably already tickets for these.
3 - and of course, ghc can be just generally slow, in the million tiny
cuts sense.

I personally haven't run into these (though I don't doubt those who
have), so don't get too discouraged!