Sébastien Pierre
I am currently evaluating different languages for implementing an application which will have to manipulate large graphs representing the structure of programs and their evolution.
Speed is in fact a crucial criterium for the language choice.
In my experience, Haskell is slow on a couple of accounts. First, I have problems getting IO to run at anything resembling C speeds. I've messed around with array IO and whatnot, but there still seems to be an order of magnitude or two. I don't know how to fix this, there have been a few remarks that indicate people can solve it, but there are still unanswered requests. If you figure it out, please let me know. Second, GHC tends to gobble a lot of memory. I think (somebody correct me if I'm wrong) a data structure like data Foo = Bar Bool Bool Bool will typically use four machine words (16 bytes) in addition to the data contents itself. You can improve things if you can make the data structure stricter, or if you can store things in UArrays instead of lists, and so on. I'd love to have a compiler that was, aggressively packing my data structures, but in the meantime, I'll just hide behind an abstract interface, and store things directly in Word datatypes. Related to this, some algorithms are slower when implemented in Haskell due to boxing and more indirection. For complex data structures (like your graph stuff probably needs), you will need much of this anyway, and implementing this in C is going to be error-prone and time consuming, and of course equally slow. Third (fourth?), Haskell is often too lazy by default, a bit of strictness will often help speed things up tremendously. Be prepared to spend a lot of time profiling time and memory to squeeze the last drop of performance from your program.
For now, the (somewhat unpleasing) conclusion I came with is that a Java (app core), Python (proto, UI) plus some interfaced C++ libs would be OK...
I think these are extraordinary choices if, as you say, speed is the most important factor. I would recommend Haskell for speed of development and correctness of implementation, but (probably) C for speed. You can of course combine the two with the FFI, but I don't know how trivial it is to pass Haskell graph structures to C and back.
What do you Haskell-experts
Oh, did I mention that I'm not an expert? I just play one on mailing lists :-) -kzm -- If I haven't seen further, it is by standing in the footprints of giants