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 _______________________________________________ ghc-devs mailing list [email protected] http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
