Trying to speedup GHC compile times...Help!

[Viktor Dukhovni]

On Fri, Jul 02, 2021 at 08:08:39AM +0000, Simon Peyton Jones via ghc-devs wrote:

> I strongly urge you to keep a constantly-update status wiki page,
> which lists the ideas you are working on, and points to relevant
> resources and tickets.  An email thread like this is a good way to
> gather ideas, but NOT a good way to organise and track them.

I remain curious as to whether "Scrap your type applications" is worth a
second look.  There are edge cases in which compile time blowup is a
result of type blowup (as opposed to code blowup via inlining).  Might
GHC have changed enough in the last ~5 years to make it now "another
compiler":

    https://www.microsoft.com/en-us/research/wp-content/uploads/2016/07/if.pdf

    (Section 4.4):

    Overall, allocation decreased by a mere 0.1%. The largest reduction was
    4%, and the largest increase was 12%, but 120 of the 130 modules showed a
    change of less than 1%. Presumably, the reduction in work that arises
    from smaller types is balanced by the additional overheads of SystemIF.
    On this evidence, the additional complexity introduced by the new
    reduction rules does not pay its way. Nevertheless, these are matters
    that are dominated by nitty-gritty representation details, and the
    balance might well be different in another compiler.

Could it be that some of the more compile time intensive packages on hackage
(aeson, vector, ...) would benefit more than the various modules in base?

Wild speculation aside, of course finding and fixing inefficiencies in
the implementation of existing common primitive should be a win across
the board, and should not require changing major compiler design
features, just leaner code.

-- 
    Viktor.