Measuring performance of GHC

[Simon Peyton Jones]

|  - One of the core issues I see in day to day programming (even though
|    not necessarily with haskell right now) is that the spare time I
|  have
|    to file bug reports, boil down performance regressions etc. and file
|    them with open source projects is not paid for and hence minimal.
|    Hence whenever the tools I use make it really easy for me to file a
|    bug, performance regression or fix something that takes the least
|  time
|    the chances of me being able to help out increase greatly.  This was
|  one
|    of the ideas behind using just pull requests.
|    E.g. This code seems to be really slow, or has subjectively
|  regressed in
|    compilation time. I also feel confident I can legally share this
|  code
|    snipped. So I just create a quick pull request with a short
|  description,
|    and then carry on with what ever pressing task I’m trying to solve
|  right
|    now.

There's the same difficulty at the other end too - people who might fix perf regressions are typically not paid for either.  So they (eg me) tend to focus on things where there is a small repro case, which in turn costs work to produce.  Eg #12745 which I fixed recently in part because thomie found a lovely small example.

So I'm a bit concerned that lowering the barrier to entry for perf reports might not actually lead to better perf.  (But undeniably the suite we built up would be a Good Thing, so we'd be a bit further forward.)

Simon