[GHC] #2442: Heuristics to improve error messages for badly
batterseapower at hotmail.com
Mon Aug 4 04:56:10 EDT 2008
2008/8/4 Simon Peyton-Jones <simonpj at microsoft.com>:
> The perf impact is zero if you have no error messages, I assume? I'm not too stressed out about extra time taken to compile failing modules.
Right: the performance degradation only occurs for modules
experiencing unbound name errors, and is proportional to a) the number
of such errors and b) the number of in-scope names.
> Mind you, doubling time for such modules sounds quite substantial, but I think you're saying that's very much a worst case.
It is: I stress tested on GHC.hs precisely because it imports an
absolutely huge number of names for the express purpose of
re-exporting them again.
> Personally I'm open to adding this -- let's see what the rest of cvs-ghc has to say.
Great. If the performance is a problem, I can probably still make it
faster, but the changes to the rest of the code will become more
invasive. Alternatively, we could just not use fuzzy-matching errors
if the in-scope name set exceeds a certain size.
> | -----Original Message-----
> | From: omega.theta at gmail.com [mailto:omega.theta at gmail.com] On Behalf Of Max Bolingbroke
> | Sent: 03 August 2008 01:32
> | To: Simon Peyton-Jones
> | Subject: Re: [GHC] #2442: Heuristics to improve error messages for badly referenced things
> | 2008/8/1 Simon Peyton-Jones <simonpj at microsoft.com>:
> | > Max
> | >
> | > What's the status of your fuzzy-matching patch. There was some Haskell Cafe discussion and I have the
> | impression that you were going to work a bit more on it.
> | >
> | > http://www.haskell.org/pipermail/haskell-cafe/2008-July/045187.html
> | >
> | > Let me know when you have a patch you're happy with
> | >
> | > Simon
> | Simon,
> | I've been able to compile GHC again today and I've verified that the
> | improved algorithm greatly reduces the performance impact. The new
> | patch and the commentary below is available with the ticket
> | (http://hackage.haskell.org/trac/ghc/ticket/2442):
> | """
> | I've solved the performance problem purely by making use of an
> | edit-distance algorithm based on bit-vectors. This is /very fast/. For
> | future reference, I've actually released it's implementation (plus
> | some other edit distances, QuickCheck tests for it all etc) on Hackage
> | (http://hackage.haskell.org/cgi-bin/hackage-scripts/package/edit-distance).
> | My stress test was compiling GHC.hs with the Module import commented
> | out. This generates a number of unbound name errors, each of which has
> | to do a full scan of the (huge) imported name set. This takes 1 second
> | on my modified GHC compared with 0.3 seconds on an unmodified one. If
> | this is not an acceptable speed I can pursue the other
> | performance-improving possibilities above.
> | """
> | Cheers,
> | Max
> Cvs-ghc mailing list
> Cvs-ghc at haskell.org
More information about the Cvs-ghc