After the recent public beta release of Safari 4, it is time to do another round of JavaScript performance testing (see the last one I did). Here I compare the unstable/development releases of different web browsers, when running SunSpider benchmark (runs/minute) and V8 benchmark (raw score). The test machine is Lenovo T61 laptop armed with Intel Core2 Duo 2 GHz, 2 GB RAM running Windows XP Professional SP2. The results follow (longer is better):
Google Chrome 2.0 is the unstable version from the developer channel, where Chrome 1.0 is the stable one. Opera 10.0 Alpha unfortunately still does not include Carakan, the brand-new fast JavaScript engine from Opera. Firefox 3.1 is tested with TraceMonkey enabled, i.e. via javascript.options.jit.chrome set to true in about:config. Konqueror 4.2 is installed from the KDE Windows project (MSVC 2005 built), the latest stable version because its latest unstable still points to 4.1.96. For safety reason, Internet Explorer 8 runs inside Xenocode browser sandbox as the sandboxing overhead was found to be negligible. The laptop's power manager tool is set to give maximum performance, thus forcing the laptop to always runs at its maximum speed.
18 comments:
it's a pity to see that firefox and konqueror suck so much compared to chrome and safari :(
The two Webkit browsers rank at the top of the list, and Konqui barely beats IE8. Konqui really needs to just make the move to Webkit at some point.
@Enderandrew both use webkit, but it is javascript performance that they are testing and the two browsers use different javascript engines (V8 and squirrelfish extreme). I don't know what the javascript support in Qt's version of WebKit is based on or how it relates to QtScript.
Meh. Misleading and useless figures...
What's the point of testing JS in isolation, on vendor-controled benchmarks for which the engines have been specifically tuned?
This is good for a marketing dept, perhaps, but doesn't reflect in anyway the real world performances.
In the real world, the JS speed bottleneck is long gone for all the browsers you tested.
As anyone know (and can readily experience), limitations are now in layout speed, rendering speed, and memory usage.
Anyway... you show once more your heavy corporate bias on KDE planet. I wonder what your blog is doing there, as you clearly have no interest in KDE.
Anon: Then I like the fact that chrome beats apples using apples own test-suite...
Can you add the QtWebKit from 4.5 to the graphs? Maybe even show the performance improvements from 4.4 to 4.5?
shouldn't you be enabling "javascript.options.jit.content" rather than "javascript.options.jit.chrome" ?
Konqueror is so far behind it's sad!
Could it be specific to the Windows port?
What JavaScript Engine Konqueror uses? KJS?
I don't think Konqueror developers are planning on developing a new JS Engine.
Good that javascript is enhanced. But I've waited other thing to fix. See my case:
http://diantn.blogspot.com/2009/02/arabic-font-rendering-issue-with-google.html
The thing is that the JIT-based engines which are leading in your benchmark (V8 and Squirrelfish Extreme) are both 32-bit x86 only. Last I checked, on x86_64, V8 doesn't even compile and Squirrelfish falls back to the bytecode engine, so there goes your performance improvement. It's sad that people trying to achieve high performance are focusing on obsolete 32-bit code when x86_64 is clearly the way to get the best performance, if they'd bother supporting it. I'm not going to run a slower 32-bit system on a 64-bit machine just to get some faster JavaScript engine to run (while slowing down everything else), nor will I litter my 64-bit installations with 32-bit multilibs just for that.
Oh, and there are also benchmarks on which KJS/Frostbyte actually competes with V8 and in several cases even beats it. Of course the V8 benchmark is made such that V8 will win.
Just for the kicks I tried to run both under Arora and Konq with the webkit kpart (Linux 32 bits, Qt4.5RC) on a machine with similar specs (by comparison, I got 119 on FFxB2 and 97 on Khtml on V8). Arora is running on Qt-Webkit.
I have no idea how you came up with these figures for Sunspider, so I ain't gonna post these.
=== V8 on Arora===
Score: 1035
=== V8 on Konq-webkit ==
Score: 1038
I think it's really nice that the kpart has no performance hit as opposed to directly using it in Arora. And these are pretty good results for beta software.
I personally hope Webkit will be used as default in the future. Unless khtml is severely improved, I can't see much hope for it. Too many sites have issues with it in my experience, and it has kept me from using it. Again, Webkit is only beta and already is more reliable for me, although it doesn't do HTTPS yet.
"Unless khtml is severely improved, I can't see much hope for it. Too many invalid sites have issues with standards compliant rendering engines in my experience, and it has kept me from using them."
There, fixed that for ya.
I've been pretty impressed with the results of Safari 4's benchmarks. My own experiments with CSS Selector Speeds have shown interesting results.( See http://selectors.turnwheel.com/ )
Safari 4 holds the top spot on average, with Chrome 2 in close second. With the current stats, Safari 4 shows a 23% lead.
Chrome 2 and Safari 4 hold the top 3 position on efficiency for every JS library tested (See http://selectors.turnwheel.com/graphs.php?v=framework ). Firefox 3.1 is falling behind compared to all the other players, but still pulls away ahead of IE8.
sigh* i wish fedora would package webkitkde :(
In KDE 4.2 firefox looks awful (even with that kde4 theme), arora's gui is buggy, because apparently oxygen style is buggy with qt4.5 and khtml/kjs can't handle digg.com
qtwebkit-kpart would solve all these horrible horrible issues :)
""Unless khtml is severely improved, I can't see much hope for it. Too many invalid sites have issues with standards compliant rendering engines in my experience, and it has kept me from using them."
There, fixed that for ya."
I know that you are totally right, but I hope you get up soon if you want to fix them. Until then, I'll use whatever works best. Webkit is one of them.
sayang sekali firefox masih berada dibawah.
Don't look to long for a qtwebkit-kpart to be the answer for Konqueror+WebKit. Konqueror has lots of internal code that calls directly into the KHTML KPart which has API above and beyond a standard KPart..
Post a Comment