Re: Unwanted eta-expansion

On Sun, Oct 9, 2011 at 10:54 AM, Roman Cheplyaka wrote:

* Jan-Willem Maessen [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/03ca9c852f06bf9a9d515056...

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