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

[Tuncer Ayaz]

On 17 February 2016 at 14:31, Tuncer Ayaz <tuncer.ayaz at gmail.com> wrote:

> On 17 February 2016 at 07:40, Evan Laforge <qdunkan at gmail.com> wrote:
>
> > 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.
>
> In my experience GHC startup overhead (time) has increased quite a
> lot somewhere in 7.x. I don't know if it's the cause, but perhaps
> dyn libs may be part of the reason. I'm not sure because I once (7.8
> I believe) tried to build without dynlink support and couldn't
> measure a substantial improvement.
>
> So, if you start ghc(i) for the first time from a spinning disk,
> it's very noticeable and quite a delay. Once it's cached, it's fast,
> so I think it's primarily due to reading stuff from disk.
>
> Just to mention the ideal overhead: anything below 400ms is small
> enough to not disrupt the flow and feels responsive. Go over 1s and
> it breaks.

Freshly booted machine with an SSD required 2 seconds for GHCi, so
maybe it's just that there's a lot more stuff to load, which leads me
to the next question: (better) dead code elimination would probably
help, where it at minimum only includes modules used, with a future
improvement of skipping unused functions, etc. as well, but I don't
know enough about GHC's DCE to talk about it.