laziness, memoization and inlining

[Scott Dillard]

Simon, Don,

You're right. -fno-state-hack fixed it. I've opened a trac ticket.
Program and test data are there.

http://hackage.haskell.org/trac/ghc/ticket/2284

Scott



On Wed, May 14, 2008 at 1:48 AM, Simon Peyton-Jones
<simonpj at microsoft.com> wrote:
> Scott
>
> | I'm experiencing some undesirable performance behavior, I suspect from
> | inlining things that shouldn't be, defeating my memoization attempts.
>
> This is bad, very bad.  I think Don is right. I believe the following is happening.  In your main program you have
>
>   do   let mesh = memoMesh rawMesh
>           display :: IO ()
>            display = draw mesh >> stuff
>        setDisplayCallback display
>        glutMainLoop
>
> So the effect is that 'display' is performed many times, by glutMainLoop.
>
> Now 'display' is seen by GHC thus:
>        display = \s -> draw mesh s >> stuff
>
> The "\s" says "given the state of the world, s, I'll draw the mesh on it".  The "state hack" makes GHC think that a "\s" will only ever be called once (which is utterly false in this case), so it can inline mesh=memoMesh rawMesh.  Result disaster.
>
>
> I bet you'll be fine if you compile your main module with -fno-state-hack.
>
> But I should fix this, somehow.  It's coming up too often to justify the hack.  Can you make a Trac bug report, and include your message and this one?
>
> Thanks for reporting it.
>
> Simon
>