
On Wed, May 6, 2009 at 2:28 PM, Don Stewart
dagit:
In particular, we need expert Haskell programmers, such as Don, to write more about how they avoid space leaks in long running apps. Again, profiling is nice, but that's more of a tuning effort.
I talk a bit about that in my LondonHUG talk:
http://www.galois.com/blog/2009/04/27/engineering-large-projects-in-haskell-...
As I said earlier: stress test with heap profiling on (is one way to absolutely ensure you know what's going on).
I wish I could have gone to the talk. I have a feeling the slides only tell part of the story. I did see these bullet points which I think are related: This one on Laziness: • Makes time and space reasoning harder! –Mostly harmless in practice – Stress testing tends to reveal retainers – Graphical profiling knocks it dead • Must be able to precisely enable/disable • Be careful with exceptions and mutation • whnf/rnf/! are your friends This one on performance: • Really precise performance requires expertise • Libraries are helping reify “oral traditions” about optimization • Still a lack of clarity about performance techniques in the broader Haskell community though The last bullet point makes me think you do agree with me :) I thought about it more since my last email, and I think what I want is something like the Effective C++ and Effective Java books, but for Haskell. A series of expert advice "items" with advice about when to use them. Real-World Haskell is a very good title, but I feel like it's at a different audience and level. Looking over Real-World haskell I see that some of these topics are discussed, which is really good. In particular, Chapter 25 would be valuable to anyone trying to find space leaks. There you discuss reduction to normal form, for example, and some strictness issues and how to control evaluation. While I'm thinking out loud, it would be very cool if someone wrote some articles, say for the monad reader, that follow the formula of the Effective C++ books. Write up the oral traditions of how to effectively use Haskell along with the dos/don'ts of each idiom. I think it could make a nice companion to the wisdom of Real-World Haskell. Have we made any tools yet that analyze haskell code and give warnings about styles and idioms that are prone to causing space leaks? For example, leaky folds are a well known problem. I know Neil Mitchel was working on some utilities to offer advice about Haskell source. Anyone know if his programs can detect potential space leaks? Thanks, Jason