Originally reported here, I distilled the example from this comment into a one file test case. Sigs.hs is exactly like NoSigs.hs, except for the fact that it has a bunch of extra type signatures that have a lot of holes. On my machine, this is what compilation times are (I gave up timing after 15 minutes):
Unfortunately, Sigs.hs and NoSigs.hs are too big to upload. Here they are on GitHub gists. Alternately, you can generate them (or rather generate very similar files, modulo some CPP) via:
The issues are AFAICT unrelated. The Happy issue is really about this - it just so happens that while attempting to reproduce that issue, I stumbled on #14683 (closed) (and incorrectly assumed it too was partial-type-signature related).
Here are some rough timings extracted from -Rghc-timing results for the files linked in #14766 (comment 148707). The table lists the mutator CPU times in seconds.
8.0.2
8.2.2
8.4.4
8.6.5
8.8.4
8.10.4
9.0.1
NoSigs.hs
17.112
16.566
16.798
1.685
1.635
1.380
1.026
Sig.hs
837.279
736.914
676.692
852.924
2.191
1.671
559.709
For NoSigs.hs there's a very remarkable improvement from GHC 8.4 to 8.6.
Even more remarkable is the development of the compile times for Sig.hs: From 8.6 to 8.8 we see a reduction of over 99%! Unfortunately, GHC 9.0.1 has introduced a massive regression. It would be great if we could fix this regression and return to the performance levels of 8.8 and 8.10.
The commit that appears to have caused the typechecker regression is 2b792fac, "Simple subsumption".
Maybe this bit from the commit message is related?!
* I fixed a serious bug in anonymous type holes. IN f :: Int -> (forall a. a -> _) -> Int that "_" should be a unification variable at the /outer/ level; it cannot be instantiated to 'a'. This was plain wrong. New fields mode_lvl and mode_holes in TcTyMode, and auxiliary data type GHC.Tc.Gen.HsType.HoleMode. This fixes #16292, but makes no progress towards the more ambitious #16082