GHC's performance
Johan Tibell
johan.tibell at gmail.com
Fri Apr 11 10:55:13 UTC 2014
On Fri, Apr 11, 2014 at 10:58 AM, Simon Marlow <marlowsd at gmail.com> wrote:
> Let me second this. In particular, I think we regress on GHC performance
> regularly, because the perf tests just aren't a good way to prevent
> regressions. When we have a +/- 10% window, someone can commit a 9%
> regression without triggering a perf failure, but the next patch to come
> along with a 1% regression will be unfairly blamed.
>
Agreed. I think graphing results helps here. It's often easier to visualize
identify which commit is the real culprit.
Aside: I think moving completely to subrepos will generally help us track
down regressions, both performance and correctness, faster. Being able to
`git bisect` your way to the cause saves a lot of time.
Furthermore, by the time we get to the perf tests we're nearly done and
> just want to push and go home, not go back and profile GHC. Yet the perf
> tests have an important purpose: the idea is to catch the problem when we
> have the crucial piece of information: the patch that caused the
> regression. Someone can try to optimise GHC later, but they have to start
> from scratch without the information about what caused the regressions.
>
> Having an automated system to track GHC performance would help a lot with
> this, I think.
Agree a 100%. Automation is what's needed here.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140411/9374b25b/attachment.html>
More information about the ghc-devs
mailing list