On Tue, Feb 16, 2016, at 05:49, Simon Peyton Jones wrote:
* We discussed it in our weekly GHC Skype chat yesterday. One thing that would really help is to make it laughably easy to track - Micro: whether my commit made anything significantly worse (compile time/allocs, run time/allocs, binary size) - Our current perf tests only complain when you go outside a window, but 90% of the lossage might have been from other patches, which demotivates dealing with it
It might be useful it phabricator ran the perf tests / nofib for every patch and displayed a warning (think a lint warning) if any of the metrics got worse. The warning would foster discussion about what caused the perf regression and whether it needs to be fixed *before* merging the patch. The current process for dealing with perf regressions seems to revolve around Joachim noticing that gipeda is reporting a regression, and raising a concern with the patch *after* it's been landed. This is entirely too late because the author will have moved on to something else, and to have to go back and work on a patch you thought was done is a bit demoralizing. To be clear, I'm very grateful for Joachim's work here, even when it involves flagging my patches :) But I think it would be better if we were *proactive* about the regressions rather than *reactive*. Eric