how to check for performance regressions caused by ghc hacking?

[Stefan O'Rear]

On Sun, Jun 03, 2007 at 05:59:34PM -0400, Isaac Dupree wrote:
> Hash: SHA1
> 
> While working on making GHC more compilable by other compilers, and
> seeing some code that would be nicer-looking refactored anyway: I want
> to change the code, but I'm afraid I'll make GHC's speed worse (these
> are critical things like FastString and FiniteMap).  I could send my
> patches to the list, but would the reviewers know any better than me
> just by looking at it? (I'm much better at mental
> strictness/sharing/etc. analysis than I used to be, at least) ... so,
> what's a good way to observe the overall speed that a GHC compiles
> things at? (Is or should this be somewhere in the GHC Commentary?  I
> didn't find anything relevant there)

We already have a Haskell runtime performance testing suite:

http://www.cse.unsw.edu.au/~dons/code/nobench

Extending it to measure compile times shouldn't be hard.  Note that
you'll have to set up your own instance, because the public instance
won't have ghc-isaacd.

(Of course, compile time measurement patches should be sent upstream)

Stefan