On 22/11/13 16:43, [email protected] wrote:
Repository : ssh://[email protected]/testsuite
On branch : master
Link :
http://ghc.haskell.org/trac/ghc/changeset/15c09a332cd24e5d6c4c9a0ede9b151c9a095f66/testsuite
---------------------------------------------------------------
commit 15c09a332cd24e5d6c4c9a0ede9b151c9a095f66
Author: Simon Peyton Jones <[email protected]>
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
_______________________________________________
ghc-devs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/ghc-devs
