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

[Eric Seidel]

On Tue, Feb 16, 2016, at 05:49, Simon Peyton Jones wrote:
> * We discussed it in our weekly GHC Skype chat yesterday.  One thing that
>   would really help is to make it laughably easy to track
>    - Micro: whether my commit made anything significantly worse
>       (compile time/allocs, run time/allocs, binary size)
>    - Our current perf tests only complain when you go outside
>      a window, but 90% of the lossage might have been from other
>      patches, which demotivates dealing with it

It might be useful it phabricator ran the perf tests / nofib for every
patch and displayed a warning (think a lint warning) if any of the
metrics got worse. The warning would foster discussion about what caused
the perf regression and whether it needs to be fixed *before* merging
the patch.

The current process for dealing with perf regressions seems to revolve
around Joachim noticing that gipeda is reporting a regression, and
raising a concern with the patch *after* it's been landed. This is
entirely too late because the author will have moved on to something
else, and to have to go back and work on a patch you thought was done is
a bit demoralizing. To be clear, I'm very grateful for Joachim's work
here, even when it involves flagging my patches :) But I think it would
be better if we were *proactive* about the regressions rather than
*reactive*.

Eric