Performance: Faster to define a function writing out all arguments?

Alexander Fuchs alexander.fuchs at uni-koblenz.de
Wed May 14 12:58:11 EDT 2008


Hi.

Simon Peyton-Jones wrote:
> | I've definitely run into the odd other case where point-freeing
> | a bit of code messes with the complexity.
> 
> That should not happen -- except for the state-hack. Which is this:
> 
> Consider
>         f1 :: Char -> IO ()
>         f1 = \c. let i = ord c in \s. print i s
> 
> Here s::State World.  Is this equivalent to
>         f2 = \c.\s. print (ord c) s
> 
> The latter is very much more efficient than 'f1', because it doesn't build an intermediate lambda.  This matters a lot in I/O-intensive programs.   But if 'f' is called thus:
> 
>         forever (f 'w')
> 
> then (ord 'w') is computed once for each call of f2, but is shared among all calls to f1.  And that can make a big difference too.

Thanks for the explanation. State World here really means the IO and ST 
monad, not the State monad, right?

Compiling with -fno-state-hack actually does actually lead to both 
versions (the point-free and explicit) being equally fast (14.4s instead 
of 15.2s resp. 14.0s). Though I am not sure why. Running in profiled 
mode makes all difference vanish.

I tested this on an Intel(R) Pentium(R) 4 CPU 3.00GHz and got the 
reported speed difference there. Using instead an AMD Athlon(tm) 64 
Processor 3800+ I got no difference even without using -fno-state-hack.


> I have no idea whether this is playing a role in the example you are discussing -- my guess is not, and there may be another performance bug lurking. So eliciting a small demo would be great.

I am sorry, I completely failed to do that. The parser builds up a data 
structure from several data types using memoization. Any significant 
simplification of the code base reduced the performance gap until it 
quickly disappeared.


	Alexander



More information about the Glasgow-haskell-users mailing list