Eight Reasons Egel is Slow

I checked the program `foldl (+) 0 {0,..,1000000}` against GHC and it's about 16 seconds for the Egel interpreter versus maybe at most 300ms for ghci. Because Egel is a term rewriter it turns out `foldl` and `foldr` have roughly the same performance. That in comparison to an old report on GHC behavior.

The odd thing is that it seems to take more time in the IRC bot, a dynamic library seems slower than the compiled interpreter. It's 16 seconds for the console application versus roughly a minute in the bot.

I am two or three orders off. That roughly corresponds to 2^8 to 2^10, so there are in the neighborhood of at least eight reasons why Egel is slower.

1. The Egel interpreter is a vannila term rewriter.
2. The interpreter doesn't optimize.
3. The language is untyped.
4. The interpreter uses idiomatic C++ and classes from the standard library.
5. Thread safe reference counting.
6. No standard arithmetic primitives.
7. The bytecode generated is dumb.
8. The overhead of exceptions.

But not bad for a simplistic robust interpreter. Not bad at all.

I love back-of-an-envelope reasoning.