[Haskell-cafe] Problems with strictness analysis?

[Derek Elkins]

On Tue, 2008-11-04 at 12:18 +0100, Patai Gergely wrote:
> Thanks everyone for the answers. I understood the underlying mechanism,
> and I did see that turning on optimisation helps, as I said in the
> comments. I just wasn't aware that this analysis is not turned on by
> default, my bad for not reading the FM.
> 
> So the final verdict is that type and strictness annotations are
> unavoidable when it comes to improving performance. This is no big
> surprise. My only problem is that if I try to write a program without
> thinking about performance first and not bothering with annotations as
> long as "it works", I end up with something that's practically
> impossible to profile as the costs spread everywhere. I'd be curious to
> hear about "best practices" to avoid this, while also getting the most
> out of type inference and various analyses to cut down on developer
> effort. How should I approach writing a large application in Haskell?

Strictness annotations aren't optimizations.  As Luke Palmer pointed
out, making something strict is a change in semantics.  Similarly for
type annotations; either they do nothing or they restrict the type which
certainly has semantic ramifications.  Neither strictness nor type
annotations should be viewed as something "outside of" your program.
They are a part of your program.

At any rate, for the particular issues you've mentioned in this thread
I'd recommend not writing code you "know" is bad in the first place, in
much the same way that Scheme programmers usually write code tail
recursively from the start.  They don't write code (non tail)
recursively and then "profile" to find the hotspots.  There are a few
well-known problematic patterns in Haskell that can be relatively easily
recognized and remedied.  Those should be dealt with as you write the
code.  Note that here I'm talking about issues like stack overflow; you
shouldn't rely on strictness analysis to avoid stack overflow, but it is
fine to rely on strictness analysis for things like unboxing and such.  

Basically, if you don't do "stupid stuff", such as well-known
anti-patterns or obviously inefficient things, then you should typically
get reasonable performance with maybe a few things that the profiler can
help you with.  If you are specifically going for performance, then
there are techniques and approaches geared toward that.