Why are monads so slow?

Why are monads so slow?

Just to get a taste of this Haskell fad, I conjured up this little benchmark:
http://pastebin.com/qgxnGaj6
It increments an integer ten thousand times in three different monads and then in a pure function.
First of all I must say that monad transformers are a bitch. It was really confusing to figure out what to lift, what not to lift, and in what order to unwrap them.
Second: I expected monad transformers to be slow, but I had hoped that at least the monads in GHC were optimized by now. After all, every Haskell program is a monad, how can you not make sure they're as tight as possible?


benchmarking Foo:
mean: 54.06153 us,
benchmarking Bar:
mean: 59.34639 us
benchmarking Baz:
mean: 392.4655 us
benchmarking Pure:
mean: 5.737042 us

The results are very dissatisfying. Monads are not only ugly and hard to work with, but they're also slow. IO-monadic code is approx. 10 times slower than pure code. Adding a StateT doesn't make things much worse, but a RWST more and your code is 6 more times slower, for a total of 60x slowdown over non-monadic code! Haskell is simply pathetic.

Well, I've improved my program, adding another test for a pure computation with an ST mutable state inside:

http://ideone.com/xFLDoE

You can compile it with "ghc -O2 --make Main.hs" and then run with "./Make -t win -u res.csv".

The results are appalling. The ST monad, which was supposed to be all about mutable speed without any IO overhead, turned out to be even slower than IO!

IO                  51 us
IO with StateT      57 us
IO + StateT + RWST 352 us
Pure                 6 us
Pure with ST         199 us

That's about 33x slowdown just for using mutable state! Haskell is really amazing at avoiding success.

>>6
>>7
Those examples are about slow code that uses monads. My benchmark is about how all code that uses monads is slow, i.e. about the inevitable overhead of using monads.