Measuring performance of GHC
Simon Peyton Jones
simonpj at microsoft.com
Tue Dec 6 08:31:30 UTC 2016
| - 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
| 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
| the chances of me being able to help out increase greatly. This was
| 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
| snipped. So I just create a quick pull request with a short
| and then carry on with what ever pressing task I’m trying to solve
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.)
More information about the ghc-devs