
On 22/11/13 16:43, git@git.haskell.org wrote:
Repository : ssh://git@git.haskell.org/testsuite
On branch : master Link : http://ghc.haskell.org/trac/ghc/changeset/15c09a332cd24e5d6c4c9a0ede9b151c9a...
---------------------------------------------------------------
commit 15c09a332cd24e5d6c4c9a0ede9b151c9a095f66 Author: Simon Peyton Jones
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. Cheers, Simon