JavaScript in Google Chrome Not So Fast 09.03.08
How well JavaScript works is what I highly concern about Google Chrome — the browser on headlines of all tech news today.
The JavaScript engine embedded in Chrome, named V8, is developed by Google which implements ECMAScript 3 and can run standalone as stated on project website.
- V8 is Google’s open source JavaScript engine.
- V8 is written in C++ and is used in Google Chrome, the open source browser from Google.
- V8 implements ECMAScript as specified in ECMA-262, 3rd edition, and runs on Windows XP and Vista, Mac OS X 10.5 (Leopard), and Linux systems that use IA-32 or ARM processors.
- V8 can run standalone, or can be embedded into any C++ application.
Of course, we’ll have to mention the tests given out by Google itself that show JavaScript speed in Chrome many times faster than in all other major browsers: IE, Firefox and Safari.
Google Chrome Benchmarks
Anyway, they are tests guided by Google and I suspect that they seem be optimized toward the best of V8. So, the better way to see how good V8 perform in action is to run tests with popular JavaScript libraries like JQuery, Prototype, Dojo, Mootools, YUI which are being used in most of web applications in real world.
In a typical web application, JavaScript is mainly used for DOM selection/ manipulation rather than for heavy calculation. That’s why all libraries try to optimize DOM selection speed for (said) faster application.
To have practical view, I decided to run Mootools’ SlickSpeed tests on Google Chrome 0.2 in comparison with Firefox 3.0.1, Safari 3.1 (Windows), IE6, Opera 9.5 and especially on the nightly build of Firefox 3.1b1pre with Tracemonkey — Mozilla’s recent effort to integrate Tamarin tracing into the existing SpiderMonkey JavaScript engine — enabled and disabled. Here are the results:
Chart: Mootools SlickSpeed Test Results
SlickSpeed Benchmarks in details
(All tests were run 10 times for each browser on Windows XP SP3, AMD x64 4400+ with 2GB RAM machine)
It turns out that Google Chrome reached 6th place ahead the poor IE6 only, 49% slower than the fastest browser: Opera 9.5. Firefox 3.1 has not proved faster than the previous version in the tests, even enabling JIT engine made the results worse. (I acknowledge that it’s just pre-release beta version and Tracemonkey is not designed for optimizing DOM manipulation).
Some other conclusions we can get out from the above results (ruling out IE6 which falls far behind others in all tests) are:
- MooTools, Prototype and Dojo get the worst performance in Chrome and surprisingly JQuery enjoys the second best result.
- JQuery’s selector performs best while YUI 2.5 provides the worst results across browsers (295% slower than JQuery) and Prototype is just slightly better than the worst (269% slower).
- JQuery’s performance is quite browser-neutral while Dojo’s defers a lot from browser to browser, yet both are well optimized for speed.
- Dojo’s selector does not play well in Firefox 3.1 currently causing several errors in tests.
Though DOM selector test does not tell everything about how fast a JavaScript engine is in real-world browsers, it brings out another aspect you may want to consider over what Google is advertising about V8 and Chrome.
I recognize that Google Chrome is really good at rendering web pages (which contributes a lot to overall performance of an application) but I’ll stick with Firefox in most of cases for I cannot find a dozen of plugins/extensions I love in Chrome yet.
Google Sites & Chrome For Dummies (For Dummies (Computer/Tech))
Das Google Chrome Praxisbuch
September 3rd, 2008 at 11:25 am
The speed of DOM manipulation is of course important, but you don’t actually measure the speed of JavaScript there. The DOM manipulation itself doesn’t happen on the JavaScript side. Basically the script only tells the DOM implementation (through some kind of interface) to do some things. The time spent on the JS side is basically 0.
But you are right. This stuff is the most important (most frequent) use case and therefore it deserves a bit more attention.
September 3rd, 2008 at 10:41 pm
[...] lập đều cho thấy V8 vượt trội trong các tác vụ thuần JavaScript (mặc dù các thử nghiệm về tìm kiếm DOM không cho kết quả khả quan như mong đợi). Hiện thời có lẽ chỉ có TraceMonkey, [...]
September 4th, 2008 at 3:32 am
[...] al curioso di trovarsi uno accanto all’altro tra i suoi feed titoli di questo tenore: JavaScript in Google Chrome Not So Fast, ma anche Google Chrome faster than Firefox, IE, [...]
September 4th, 2008 at 3:48 am
Interestingly, on my own AJAX and Sofu based Website, Chrome is really 3 times faster, even though I didn’t optimize it towards it. Chrome even provides the same smooth moves and picture quality from Safari, which Firefox still lacks. (Transparent Gifs over other pictures following the mouse (i.e window drag) distort the underlying image a lot)
September 4th, 2008 at 4:18 am
Most of the users does not cares and know about these test, their simple concern is that the page should open faster, and chrome is capable of loading pages faster than any other browser.
September 4th, 2008 at 5:28 am
Why test these latest versions against a version of IE that came out 7 years ago? Seems very odd.
September 4th, 2008 at 6:55 pm
Hey Google fanboys, I’m tired of browser war — now come another browser to test for my web apps.
OK, Chrome is fast, so what? It’s new, no burden with many historical codes, not have many plugins yet. I’ll see how fast it is in 2 years later.
@fimbas: DOM selector is an important test; user may not care about it but web developer cannot ignore it.
September 5th, 2008 at 9:19 am
Google Chrome is really fast!
Now I can sort 200,000 records inside of Browser (Chrome) just in 1 sec. (Faster than Microsoft Excel):
http://www.ardentedge.com/ex_if.htm
September 15th, 2008 at 11:05 am
We have performed some measurements on the performance of http://www.taskwriter.com . The results show Firefox 3.0 and Chrome being pretty close. By no means as far as Google suggests with its tests.
Full details and graph here : http://www.taskwriter.com/blog/how-good-chrome-really-is/
btw, http://www.taskwriter.com is written using google web toolkit…so advantage for Chrome here.
September 19th, 2008 at 3:28 am
Could you add a current Safari / Webkit-Nightly in your comparison?
Cause it doesn’t make much sense to compare beta browsers like Chrome or IE8 with shipinng browsers.
September 22nd, 2008 at 9:14 am
According to your assertions, V8 JavaScript isn’t as fast as touted, but your benchmarks are not testing the JavaScript engine, but the DOM engine.
Testing the V8 JavaScript engine only gave me results about 8 times faster than FireFox and about 63 times faster than MSIE 7. As it turns out, the V8 isn’t a JavaScript interpreter, but compiles JS directly into machine code. Since they have intentionally not optimized their engine yet, it will be interesting to see what the open source community will accomplish in the next few months.
There is a unique case where V8 fails to shine and that is when the JavaScript runs functions only once or uses huge amounts of eval code, in which case the speed is about the same as both FireFox and MSIE.
November 16th, 2008 at 8:40 pm
[...] lập đều cho thấy V8 vượt trội trong các tác vụ thuần JavaScript (mặc dù các thử nghiệm về tìm kiếm DOM không cho kết quả khả quan như mong đợi). Hiện thời có lẽ chỉ có TraceMonkey, [...]
April 29th, 2009 at 7:42 am
Using the Selector function as the test for javascript speed isn’t exactly useful; for browsers which support it, most of the libraries will translate the CSS selector to its xpath equivalent, and use the native xpath support.
A better test would be a hard parser - the interpreted JSON libs, for example.