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