The only difference in generated code is in the showsPrec function for a newtype-wrapped Int (ThreadId).
The code actually never (explicitly) uses Show instance -- it's only needed as a dependency for Num instance. Could it be some cache effect? I'll see if I can reduce that code and then will file a bug. * Simon Peyton-Jones <simo...@microsoft.com> [2011-10-12 10:56:04+0000] > Roman, Jan-Willem > > I'm maxed out at the moment, and will be so for at least a week. > > If you think there is something mysterious and J-W agrees, could you create a > ticket, with the smallest example you can, and instructions to reproduce? > That'd be brilliant. > > Of course, Jan-Willem, if you have a moment to diagnose a bit more about WHY > it's going slower that would be even better! > > Thanks > > Simon > > | -----Original Message----- > | From: glasgow-haskell-users-boun...@haskell.org > [mailto:glasgow-haskell-users- > | boun...@haskell.org] On Behalf Of Jan-Willem Maessen > | Sent: 10 October 2011 02:51 > | To: Roman Cheplyaka > | Cc: glasgow-haskell-users@haskell.org > | Subject: Re: Unwanted eta-expansion > | > | On Sun, Oct 9, 2011 at 10:54 AM, Roman Cheplyaka <r...@ro-che.info> wrote: > | > * Jan-Willem Maessen <jmaes...@alum.mit.edu> [2011-10-08 12:32:18-0400] > | >> It seems to be a common misconception that eta-abstracting your > | >> functions in this way will speed up or otherwise improve your code. > | >> > | >> Simon PJ has already provided a good explanation of why GHC eta > | >> expands. Let me take another tack and describe why the code you wrote > | >> without eta expansion probably doesn't provide you with any actual > | >> benefit. Roughly speaking, you're creating a chain of closures whose > | >> contents exactly describe the contents of your list (ie you've created > | >> something that's isomorphic to your original list structure), and so > | >> you should expect no benefit at all. > | > > | > Thanks for the analysis. > | > > | > I used myFoldl as a minimal example to ask the question. > | > > | > Here's an example of real code where this does make a difference: > | > https://github.com/feuerbach/regex- > | applicative/tree/03ca9c852f06bf9a9d51505640b8b72f07291c7d > | > | Ah, now things get more complicated! :-) I suspect here you're > | actually entering the regexp closures, and compiling it down is > | actually saving you a teensy bit of interpretive overhead. > | > | > ... > | > What's even more interesting (and puzzling!), if remove > | > -fno-do-lambda-eta-expansion for Text/Regex/Applicative/Types.hs, > | > the benchmark takes 2.82 seconds. > | > | That *Is* odd. The only obvious code generated here would be the > | newtype instances, for which this should surely be irrelevant? Can > | someone at GHC HQ explain this one? > | > | -Jan > | > | _______________________________________________ > | Glasgow-haskell-users mailing list > | Glasgow-haskell-users@haskell.org > | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users -- Roman I. Cheplyaka :: http://ro-che.info/ _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
