A recurring topic of concern among users of GHC is GHC’s performance, both regarding compilation time and runtime of the generated code, and how GHC’s performance evolves across GHC releases. That concern is aggravated by the long release cycle and the small footprint of libraries in CI builds. As a datapoint that lends credibility to this concern, consider that, although an explicit goal for GHC 8.2 is to improve compilation times, there is evidence that compilation times (for a release candidate) degraded for some packages.

In this talk, we will analyse the current situation and propose a scheme that enables the (a) continuous monitoring of GHC performance on (b) a wider range of packages. As our scheme is based on Stackage package sets, we will also argue that widening the range of packages under CI will accelerate the adoption of new GHC releases by the wider community. In particular, we will detail our own plans to work towards an implementation of the proposed scheme as well as outline where we hope for community support. Our focus here is on tracking compilation times, but the proposed scheme will also get us closer to being able to track the runtime performance of GHC generated code beyond nofib. Finally, by widening the surface area of CI, we may also be able to spot functional regressions on code beyond the GHC build and its test suite more quickly.