[webkit-dev] Is WebKit's javascript subpar?

[Maciej Stachowiak]

Hi Mike,

On May 26, 2006, at 1:11 PM, Mike Emmel wrote:

>> Another issue with SpiderMonkey is that it's far slower than  
>> JavaScriptCore, and
>> speed is a big priority for us.
>
> Thats a bold statement considering one is bytecode based and the other
> uses a tree.
>
> Can you show where the engine test were performed results etc etc.
> I simply can't believe this with out a very large test suite.

It would be more accurate to say that JavaScriptCore is faster than  
SpiderMonkey for some workloads. For others it is slower.

Two benchmarks where we know we are measurably faster by a  
significant margin are the iBench JavaScript processing benchmark,  
and the 24fun benchJS test. The former is not publicly available at a  
live site, but you can download it and try it yourself. The latter  
can be found at http://www.24fun.com/downloadcenter/benchjs/ 
benchjs.html.

To be fair, these tests measure more than just raw JS engine  
performance, they also cover other aspects of engine performance. And  
they also do not give thorough coverage of every possible thing in  
JS. But they are useful examples of real-world workloads.

We also know of microbenchmarks where Firefox (or Opera, or IE) is  
significantly faster. We're definitely working on making those  
faster. You are welcome to do your own measurements.


To comment on the actual idea of somehow replacing the internals of  
JavaScriptCore with SpiderMonkey: There are a lot more differences  
between our engines than just bytecode vs. recursive tree calls.  
Consider:

1) Our code base is significantly smaller and easier to understand  
than SpiderMonkey. Hackability is important to us, and we've found  
that it's often easier to optimize clear, simple code than to make  
hairy code easy to understand.

2) Our technology for binding to native object implementations is  
significantly higher performance than SpiderMonkey's. For use on the  
web, efficient access to DOM calls is extremely important and indeed  
we show much better results on many DOM benchmarks (e.g. http:// 
idanso.dyndns.org/maps/jsbench/ although a lot of this is due to the  
core DOM code being faster).

3) We've extensively micro-optimized many aspects of our engine  
besides just the core interpreter, such as the object/value  
representation and the garbage collector. Collectively these  
optimizations make a big difference.


We've also started an experimental branch to build a more bytecode- 
like iterative interpreter (treecode-branch). We've put it aside for  
now because it is not yet as fast as our current interpreter, but we  
plan to come back to it. In general, we are more interested in  
continuing to improve and rearchitect our own code and to drop it and  
replace it with something else. We want to make sure we keep the  
advantages our JS interpreter already has.

And I think it is good for the long-term health of the web for there  
to be multiple implementations of things. If you have a single  
implementation, you end up coding to the implementation and not to  
any kind of standard, and fixing bugs becomes impossible.


Finally, I think this thread has wandered way off topic. As many  
people have mentioned, the WebKit bugs that people do run into are  
rarely with the core JS engine itself. Typically they are issues in  
the DOM and other components that are accessed through JavaScript.  
Replacing the JS interpreter would not do anything to resolve these  
kinds of issues.

Regards,
Maciej