Jason Dagit wrote:
I don't mean to undermine your marketing efforts, but I don't think this is gossip driven.
I know from experience that lambdabot tends to be leaky. Otherwise, lambdabot wouldn't be running on my server to begin with. And, even so, Cale monitors lambdabot to make sure it is not using too many resources (and I complain when/if I notice it). I have heard similar stories related to hpaste and happs. I have also experienced it with writing a forever loop in Haskell that did polling from channels. I would leave my app running for, say, 4 hours and it would be using tons of memory.
I think it's fair to say that keeping the memory usage low of a long running Haskell app is hard, but that is a general issue not just a Haskell issue. It's hard in most languages. I think what we need to address this is more information about preventative measures. What programming styles cause the problem and which ones solve it. I would say that I lack confidence recommending anyone to use Haskell for long running processes because I don't understand well the problem of keeping the usage low. If it is a well documented problem with documented solutions (more than just profiling), then I would regain my confidence because I know the problem can be worked around reliably. Does this make sense? Maybe it's already well documented?
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.
Mmm, interesting. Clearly I don't run anything for long enough to notice this effect. (I just had a look at a Haskell program I wrote myself which I happen to have running in the background right now. Process Explorer tells me it's used 4 hours of CPU time, and it's memory graph is still flat. It was reading 106 MB shortly after I started it, and it still says 106 MB now. OTOH, it's a fairly trivial program, so...) But if you're going to advocate more expert knowledge being diseminated, I certainly won't argue against that! :-D Export knowledge is something it seems difficult to have too much of...