mike.emmel at gmail.com
Fri May 26 15:00:22 PDT 2006
Thanks for the response I felt that overall Webkit is significantly
faster and I agree
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
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
> >> 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.
> SpiderMonkey for some workloads. For others it is slower.
> Two benchmarks where we know we are measurably faster by a
> 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/
> 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
> between our engines than just bytecode vs. recursive tree calls.
> 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
> Replacing the JS interpreter would not do anything to resolve these
> kinds of issues.
More information about the webkit-dev