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

[Mike Emmel]

Thanks for the response I felt that overall Webkit is significantly
faster and I agree
with everything your saying. With the amount of javascript coded in
modern AJAX apps not having a bytecode engine could lead to
significant performance problems with Web2 apps.

You should mention the branch on the web page I'm sure others would be
willing to persue it
if you explain the javascript project  page it does not need to sit.

Thanks agian

Mike


On 5/26/06, Maciej Stachowiak <mjs at apple.com> wrote:
>
> 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
>
>
>