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

On Wed, Feb 17, 2016 at 2:21 PM, Ben Gamari wrote:

Thomas Tuegel 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!