Comments on: WebKit’s JS Interpreter was an AST walker

By: Pinku

Pinku — Thu, 05 Jun 2008 14:16:27 +0000

Thanks for your comments. Rather than describe WebKit’s interpreter as “slow”, I should have said “an architecture that is known to be slow”. But then it’s faster than existing bytecode interpreters, which means the others are doing something terribly wrong. I should take a look at SpiderMonkey to see what’s going on in there.

By: Mark Rowe

Mark Rowe — Wed, 04 Jun 2008 21:09:52 +0000

Oh, and it seems a little strange to pick on JavaScriptCore’s *old* interpreter when the new interpreter design matches quite closely with what you describe as being a better approach.

By: Mark Rowe

Mark Rowe — Wed, 04 Jun 2008 21:09:13 +0000

Ruby is another popular interpreter that makes use of AST-walking as its primary means of execution. As you mention, it is a very naive approach to performance and there are higher-performance alternatives available. That said, WebKit’s old JavaScript interpreter was as as fast or faster than the other JavaScript implementations on all benchmarks (Mozilla, Opera, IE, etc).

A better direction for thought may be why the naive AST-walking interpreter that JavaScriptCore previously used is as fast (and often faster) than the more “advanced” designs used in the interpreters of Mozilla, Opera and IE.

By: Oliver

Oliver — Wed, 04 Jun 2008 20:14:21 +0000

Errr, the old interpreter was not “slow”, in fact it was the fastest JavaScript interpreter out there (WebKit3.1 has the fastest released interpreter, and the nightlies prior to merging SquirrelFish were the fast unreleased JS interpreter).

That SquirrelFish is even faster does not change the fact that the old interpreter was fast.

By: Maciej Stachowiak

Maciej Stachowiak — Wed, 04 Jun 2008 19:59:38 +0000

While bytecode is a better architecture, note that the old AST interpreter was highly optimized and achieved speed comparable to the fairly well optimized SpiderMonkey bytecode interpreter for JavaScript (and beat the pants off of Opera’s and IE’s bytecode interpreters). It’s not just the architecture that matters, it is the implementation quality. So if you want to throw around terms like “shockingly slow”, I would say you should base it on measurements, not theory based on the architecture. You would be surprised how much it is possible to speed up a tree-based interpreter.

(As another example, many would say that a JIT is faster than a regular bytecode interpreter; but SquirrelFish is faster than some known JIT-based JS implementations.)