simonpj at microsoft.com
Wed Oct 12 12:56:04 CEST 2011
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!
| -----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-
| 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?
| Glasgow-haskell-users mailing list
| Glasgow-haskell-users at haskell.org
More information about the Glasgow-haskell-users