[Haskell-beginners] Lazy vs Strict ponderings...

[Daniel Fischer]

On Sunday 20 March 2011 10:37:23, Heinrich Apfelmus wrote:
> sean at objitsu.com wrote:
> >>> 2) Don't worry about memory leaks until they actually appear. If
> >>> they do, use a profiling tool to find out what's going on. Most
> >>> likely, one of the two things above happened in an interesting way.
> > 
> > At the risk of sounding stupid in Haskell mode, how would I be aware
> > of this other than obvious messages or seg-faults about memory
> > getting low ?
> 
> The usual sign is that GHC is requesting more RAM from the OS than it
> should. For instance, if you expect your program to run in constant
> space, but GHCs memory usage keeps growing by 100 MB every twenty
> seconds, then you have a space leak. You can also run a profile
> preemptively and look at the graph.
> 
>    http://book.realworldhaskell.org/read/profiling-and-optimization.html
> 

Before profiling, I'd first

a) watch in top [whatever the corresponding utility is called on Windows]
b) run with +RTS -s (requires to link with the -rtsopts flag in GHC >= 7)

to see whether there's a problem.
Important in the +RTS -s output are (for this)
- GC time
- maximum residency
- total memory in use

The total allocation figure is rather irrelevant, don't worry if that's 
high but the above are small.

If the memory usage is much higher than you'd expect, you likely have a 
memory leak (but be aware that datatypes like lists and trees have fairly 
large overhead).

If GC time is large but memory usage is small enough, you have a problem 
which is technically not a memory leak, but requires similar diagnosis and 
remedies.

If the above indicates a problem, unless it's obvious where the problem 
must be (and it rarely is), profile to locate it.

However, the interaction of profiling and optimisations is quite 
complicated (some optimisations are impossible when compiling for profiling 
if they would eliminate a cost-centre) and compiling for profiling can 
occasionally change the time/space behaviour of a programme.
So it might be that the profiling run doesn't show a problem present in the 
production build (indicates that some optimisation is in fact a 
pessimisation in your case) or shows a problem not present in the 
production build (some optimisation eliminating the leak is prevented by 
profiling bookkeeping).
Both effects are rare, though. Nevertheless I like to confirm the existence 
of a problem before profiling.

> >> It is likely that, if you develop a medium to large sized application
> >> for a customer, memory leaks will appear at the customers site. It
> >> will often be very difficult to reproduce the situation and find the
> >> leak.
> > 
> > That scares me enough to not want to use Haskell for serious
> > application development. With 26 years in the trade I have had too
> > many times when a fault cannot be reproduced and despite an 'obvious
> > fault in the source' being fixed and the problem never coming back,
> > without being able to reproduce and thus confirm that you have
> > eliminated the problem, you can't ever relax on a Saturday night! LOL
> > 
> > I hate the word 'random' when clients describe problems too!

The good thing is that most common space leaks are pretty reliable, so you 
shouldn't hear that word too often ;)

> 
> That were the fears that I wanted to address with "don't worry". :D
> 
> You see, the thing is this: any kind of error can happen at the
> customer's site, be it memory leaks, dangling pointers, division by zero
> or all the nasty bugs you put in your code. The programming language you
> choose influences both the kind of errors and the frequency of errors.
> Choosing Haskell over an imperative language like C, Pascal or Java
> drastically reduces logic bugs, and hence the total frequency of errors,
> even though you might be slightly worse off on the memory leak side,
> because laziness introduces a complication there.

A small caveat. Before you've gathered the experience to avoid the common 
traps, you can be more than 'slightly worse off on the memory leak side', 
so it's probably a good idea to hone your skills on smaller projects first.

> But that is a small price to pay for the general reduction in errors.
> 
> >> See also "On the reliability of programs",
> >> http://www.cs.utexas.edu/users/EWD/transcriptions/EWD03xx/EWD303.html
> 
> Dijkstra would be very happy about how close mathematics and Haskell
> are.
> 
> 
> 
> Regards,
> Heinrich Apfelmus