[Haskell-beginners] Lazy vs Strict ponderings...
daniel.is.fischer at googlemail.com
Sun Mar 20 15:55:24 CET 2011
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.
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
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
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
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
> Heinrich Apfelmus
More information about the Beginners