2008/8/4 Simon Peyton-Jones <[EMAIL PROTECTED]>: > Max > > 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. > http://www.haskell.org/pipermail/haskell-cafe/2008-July/045187.html 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. Cheers, Max > Simon > > | -----Original Message----- > | From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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 <[EMAIL PROTECTED]>: > | > 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 > [email protected] > http://www.haskell.org/mailman/listinfo/cvs-ghc > _______________________________________________ Cvs-ghc mailing list [email protected] http://www.haskell.org/mailman/listinfo/cvs-ghc
