Unwanted eta-expansion

[Roman Cheplyaka]

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 <simonpj at 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-bounces at haskell.org [mailto:glasgow-haskell-users-
> | bounces at haskell.org] On Behalf Of Jan-Willem Maessen
> | Sent: 10 October 2011 02:51
> | To: Roman Cheplyaka
> | Cc: glasgow-haskell-users at haskell.org
> | Subject: Re: Unwanted eta-expansion
> | 
> | On Sun, Oct 9, 2011 at 10:54 AM, Roman Cheplyaka <roma at ro-che.info> wrote:
> | > * Jan-Willem Maessen <jmaessen at 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 at haskell.org
> | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

-- 
Roman I. Cheplyaka :: http://ro-che.info/