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
_______________________________________________
webkit-dev mailing list
[email protected]
http://www.opendarwin.org/mailman/listinfo/webkit-dev
