>
> · Everyone. It’s really hard to keep focus on keeping GHC’s
> compilation time and space down. Everyone is usually focused on bugs and
> features. It would be incredibly helpful if someone, or a small group, could
> build a profiled version of GHC 7.8, 7.10, and HEAD, and track down what is
> happening. Usually there are multiple causes, but a factor of 7.5 ought not
> to be hard to nail down.
>
> Please!
This is a great newcomer-to-ghc-hacking task. It's both relatively easy to do
and gives a newcomer a chance to tour the codebase. The person doing the
profiling doesn't also have to fix the bug. Just knowing what module or
component of GHC is causing the trouble helps immensely.
As a further plug: when a change I made introduced a performance regression, I
went into the debugging process very warily, expecting profiling GHC to be
painful. It was just the opposite -- remarkably straightforward and able to
produce results without terribly much effort. On the other hand, it does
generally require having multiple (profiled) builds of GHC to get meaningful
comparisons.
Thanks to whoever takes this on!
Richard
_______________________________________________
ghc-devs mailing list
[email protected]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
