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

[Thomas Tuegel]

On Wed, Feb 17, 2016 at 2:21 PM, Ben Gamari <ben at smart-cactus.org> wrote:
> Thomas Tuegel <ttuegel at gmail.com> writes:
>> I have contributed several performance patches to Cabal in the past,
>> so I feel somewhat qualified to speak here. The remaining slowness in
>> `cabal build` is mostly due to the pre-process phase. There work in
>> progress which may improve this situation. We could also look at
>> separating the pre-process phase from the build phase. (It seems odd
>> to call it `pre-process` when it is *always* run during the build
>> phase, doesn't it?) This has the advantage of sidestepping the
>> slowness issue entirely, but it may break some users' workflows. Is
>> that trade-off worth it? We could use user feedback here.
>>
> What exactly does the pre-process phase do, anyways?

It runs the appropriate pre-processor (Alex, Happy, c2hs, etc.) for
modules that require it. It's slow because of the way the process is
carried out: For each module in the package description, Cabal tries
to find an associated .hs source file in the hs-source-dirs. If it
cannot, it looks for a file with an extension matching one of the
pre-processors it knows about. If it finds one, it runs the
corresponding program if the output files are missing or outdated.

If this doesn't sound TOO bad, consider: how many modules on Hackage
use pre-processors? Certainly less than 5%, maybe even less than 1%.
That's a LOT of work every time you call `cabal build`.

- Tom

P.S. If I may get a little philosophical, this is representative of
the problems we have in Cabal. Cabal tries to be very automagical, at
the cost of being sometimes slow and always opaque when things break!