Some programs can produce very deeply nested types of non-linear size. See Scrap your type applications for a way to improve these bad cases
#9198: large performance regression in type checker speed in 7.8
Types in Core blowing up quadratically (as seen in -ddump-ds output)
One theme that seems to pop up rather often is the production of Core with long strings of coercions, with the size scaling non-linearly with the size of the types in the source program. These may or may not be due to similar root-causes.
A bit difficult to decipher, since a lot of the stats/surrounding numbers were totally rewritten due to some Testsuite API overhauls.
The results are a mix; there are things like peak_megabytes_allocated being bumped up a lot, but a lot of them also had bytes_allocated go down as well. This one seems pretty mixed.
7.8 vs 7.10
Things mostly got better according to these, not worse!
Many of them had drops in bytes_allocated, for example, T4801.
The average improvement range is something like 1-3%.
But one got much worse; T5837's bytes_allocated jumped from 45520936 to 115905208, 2.5x worse!
7.10 vs HEAD
Most results actually got better, not worse!
Silent superclasses made HEAD drop in several places, some noticeably over 2x
max_bytes_used increased in some cases, but not much, probably GC wibbles.
No major regressions, mostly wibbles.
(NB: Sporadically updated)
As of April 22nd, 2016:
GHC HEAD: 14m9s (via 7.8.3) (because of Joachim's call-arity improvements)
GHC 7.10: 15m43s (via 7.8.3)
GHC 7.8: 12m54s (via 7.8.3)
GHC 7.6: 8m19s (via 7.4.1)
Random note: GHC 7.10's build system actually disabled DPH (half a dozen more packages and probably a hundred extra modules), yet things *still* got slower over time!
Interesting third-party library numbers
Compile time of some example program (fluid-tree) of fltkhs library increased from about 15 seconds to more than a minute (original message).
GHC takes significantly more memory compiling the xmlhtml library with -j4 than -j1 (1GB vs 150MB). See #9370.
The Language.Haskell.Exts.Annotated.Syntax of haskell-src-exts takes many tens of seconds to compile. Howeever, this may not be surprising: Consists of roughly 70 data definitions, some with many constructors, deriving (Eq,Ord,Show,Typeable,Data,Foldable,Traversable) on most of them as well as defining Functor.
vector-algorithms may be a nice test and reportedly got slower to compile and run in recent GHC releases.
91c6b1f54aea658b0056caec45655475897f1972 is a refactoring of the Typeable implementation which moves Typeable dictionary generation from evidence generation time to the point where the represented type is defined. This tends to regress compile allocations by a few percent for programs defining lots of types (although programs which make large use of Typeable may see improvement).
eb3d6595735671605c5d6294a796dc0f16f784a4 ("OccName: Avoid re-encoding derived OccNames") is a refactoring which reduces allocations in the computation of derived OccNames by eliminating String intermediates.