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

On 17 February 2016 at 14:31, Tuncer Ayaz wrote:

On 17 February 2016 at 07:40, Evan Laforge 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.