On Wed, May 16, 2012 at 8:40 AM, Gregg Lebovitz <span dir="ltr"><<a href="mailto:glebovitz@gmail.com" target="_blank">glebovitz@gmail.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
1) Does Haskell and its libraries need performance improvements? Probably yes. Some of the performance issues seem to be related to the way the language is implemented and others by how it is defined. Developers really do run into performance issues with Haskell and either learn to work around the issue or try to fix the offending implementation. The wiki performance page gives insight into some of the performance issues and how address them.<br>
</blockquote><div><br></div><div>I think there is a closely-related issue: that you'll need to learn how to debug subtle performance problems <i>early</i> in your Haskell programming career. In particular</div><div><br>
</div>
<div><ul><li>you will have space leaks and related performance problems in naively-written programs</li><li>you will consequently need to learn how to use strictness annotations and other related language features, and how to use the profiler to determine where they're needed</li>
</ul><div>For example, imagine you're new to the language, and as an exercise decide to write a program that counts the characters on standard input and writes the count to standard output. A naive program in, say, Python will probably use constant space and be fairly fast. A naive program in Haskell stands a good chance of having a space leak, building a long chain of thunks that isn't forced until it needs to write the final answer. On small inputs, you won't notice. The nasty surprise comes when your co-worker says "cool, let's run it on this 100 MB log file!" and your program dies a horrible death. If your friend is a sceptic, she'll arch an eyebrow and secretly think your program -- and Haskell -- are a bit lame.</div>
</div><div><br></div><div>The example is contrived, but it's a very common task to consume some big stream of input and produce a much smaller summary of it. I think it's fair to say that you have to be a slightly sophisticated Haskell programmer to do those kinds of things correctly, at least compared to more mainstream languages.</div>
<div><br></div><div>My experience is that this is perhaps the most important 'problem' with Haskell performance. Not so much that it's typically two or three or ten times slower than language X, but that it's easy to have a bad experience <i>early on</i>, one that seems inconsistent with the language shoot-out and other performance comparisons.</div>
<div><br></div><div>Kevin</div><div>-- </div></div>Kevin Charter<br><a href="mailto:kevin.charter@acm.org" target="_blank">kevin.charter@acm.org</a><br>