Why are intepreters so slow today

Skip Montanaro (montnaro@ausable.crd.ge.com)
Fri, 15 Apr 94 10:25:46 EDT


As was pointed out by other responders, you've selected an example for which
interpreters are particularly bad choices. LYMB, our internal interpreted
object-oriented language is also crummy at your example. Even when all the
optimizations we can perform are made (I think there are two... :-), running
an increment loop with only 100,000 iterations takes nearly 20 seconds on a
SPARCstation-10, but that's to be expected, since the loop itself is
implemented as an object. The first iteration of the increment loop
generates about 50 messages. The second (and successive) iteration
generates less than 10 messages. Each message send requires several
function calls. Your C loop has no function calls at all.

However, suppose you want to put together a complex computer animation and
your choices are LYMB or C. The speed of the two won't be terribly
different, because most of the significant work is done in the LYMB classes,
which are written in C. Message passing overhead (and other interpretation
overhead, like parsing and lexical analysis) approaches zero. Programmer
productivity is much higher, so there's a big win for LYMB over C.

The moral of the story is pick the correct tool for the job you want to do.

Skip (montanaro@crd.ge.com)