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

[Jonas Munk]

I agree. I have done a fair amount of (imo advanced) JavaScript  
lately for Safari, FF and IE. I have had no problems with WebKits  
JavaScript impl. The only problem is the missing features of the DOM.  
But that is no surprise since WebKit is still relatively young. And  
you will always have features that are missing on one or the other  
browser. I have hacked scriptaculous and prototype a number of times  
to fix "bugs" where they assumed too much about the browser. (Ive  
also seen IE on Windows spawning a blue screen when just including  
the two aforementioned libs in a page :-))

Jonas

Den 26/05/2006 kl. 23.09 skrev 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
>
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at opendarwin.org
> http://www.opendarwin.org/mailman/listinfo/webkit-dev