Haskell performance

Ketil Malde ketil+haskell at ii.uib.no
Thu Mar 18 10:22:44 EST 2004

Sébastien Pierre <sebastien.pierre at adival.com> writes:

> 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

> What do you Haskell-experts 

Oh, did I mention that I'm not an expert?  I just play one on mailing
lists :-)

If I haven't seen further, it is by standing in the footprints of giants

More information about the Glasgow-haskell-users mailing list