[GHC] #2442: Heuristics to improve error messages for badly
simonpj at microsoft.com
Mon Aug 4 03:59:27 EDT 2008
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.
Mind you, doubling time for such modules sounds quite substantial, but I think you're saying that's very much a worst case.
Personally I'm open to adding this -- let's see what the rest of cvs-ghc has to say.
| -----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
| 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
| 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
| 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.
More information about the Cvs-ghc