[commit: testsuite] master: Higher residency in Haddock (15c09a3)

Simon Marlow marlowsd at gmail.com
Thu Nov 28 12:30:49 UTC 2013

On 22/11/13 16:43, git at git.haskell.org wrote:
> Repository : ssh://git@git.haskell.org/testsuite
> On branch  : master
> Link       : http://ghc.haskell.org/trac/ghc/changeset/15c09a332cd24e5d6c4c9a0ede9b151c9a095f66/testsuite
>> ---------------------------------------------------------------
> commit 15c09a332cd24e5d6c4c9a0ede9b151c9a095f66
> Author: Simon Peyton Jones <simonpj at microsoft.com>
> Date:   Fri Nov 22 16:42:43 2013 +0000
>      Higher residency in Haddock
>      I think there really is a slight worsening in the situation here, but
>      it needs someone to build a profiled compiler and take a proper look.

Maybe make a ticket for the next milestone then?

I'm getting slightly worried that we keep pushing these performance 
bounds up without really investigating why.  The great thing about the 
perf tests is that they catch something immediately, rather than us 
having to bisect it or do lengthy profiling investigations later.

What should we do about this?  I realise it's a pain when you've got a 
working patch and the only thing holding it up is some random perf test 
that seems to be completely unrelated.  Let's have a brainstorm on how 
we can improve things.  What tools can we build to help?  Maybe this is 
a good way that new contributors could get involved.

Here's one idea off the top of my head: let's make a way to take heap 
samples at deterministic points during compilation, say between phases. 
  Then make a tool to compare profiles made this way, so that we can say 
what changed between two compiler versions.  I'm pretty sure this will 
spot leaks pretty quickly, and tell you something about what is leaking 
(which constructors).

I think we've accrued some bloat recently.  I had to increase the memory 
in my VM because it ceased to be able to build HEAD at some point.


More information about the ghc-devs mailing list