The postings on this site are the contributor's and don’t necessarily represent IBM’s positions, strategies or opinions.
GWT performance with the latest JavaScript engines
October 22nd, 2008 Alex Moffat Posted in GWT | 8 Comments »
There are three new JavaScript engines out now in browsers, at least three I know about. Google Chrome has V8. Firefox 3.1 Beta has TraceMonkey and the WebKit Nightly Builds, which will become the engine for Safari at some point, has SquirrelFish Extreme. All of these are meant to be much faster than current implementations and I’ve seen various benchmarks around the web showing their relative performance. Most of the measurements seem to be for synthetic benchmark code so I thought it would be interesting to see how these engines handled Lombardi Blueprint as it’s a large GWT application with client side diagram layout and line routing that pushes the boundaries of what you can do in JavaScript.
I recorded timings for six different browsers, IE7, Chrome (V8), Firefox 3.0.1, Firefox 3.1 Beta 1 with jit turned on (TraceMonkey), Safari 3.1.2 and WebKit r37604 (Squirrelfish Extreme). I used existing timing statements in our code to measure how long it takes to layout, route and render the largest diagram we currently have, running each test 10 times. All of the tests were run on the same VM on my OS X box. The JavaScript was compiled by GWT with the OBF option. Finally, as the absolute results are not really relevant I normalized the timings to show them as a percentage of the IE7 time. In the graph smaller bars are better, and the X axis shows the performance as a percentage of the IE7 time, which therefore, of course, shows as 100.
WebKit is clearly the winner at around 20 times faster than IE7, though I’m confused/intrigued by the Firefox results. Why don’t I see Firefox 3.1 Beta 1 beating Firefox 3.0.1? I’ll have to rerun these measurements with a later 3.1 build at some point. If anyone can tell me what else I could have failed to do for Firefox I’d be interested, possibly there is some configuration I have set incorrectly.
The larger result is that the new JavaScript engines are very, very fast. I know I said above that absolute numbers weren’t relevant but WebKit executes in 274ms code that takes IE7 5s to run. Speed like this should let us do more interesting things in our application in the future. On the other hand, Blueprint still has to support IE6 and IE7, and IE6 is even slower than IE7. One way round this would be to offer an enhanced experience for more modern and faster browsers that can support it and a standard experience for IE6 and IE7.
October 23rd, 2008 at 3:08 am
Hi,
I think TraceMonkey wasn’t enabled during your tests
In the beta version of FF3.1, it is disabled.
Here is how to set it up :
http://www.tech-recipes.com/rx/3381/firefox-31-how-to-enable-the-tracemonkey-javascript-engine/
Regards,
Samuel
October 23rd, 2008 at 3:25 am
One thing to note: JavaScript engine != rendering engine. As soon as you deal with the DOM, the JavaScript engine isn’t anymore the only thing entering into play.
IE is known to have both a poor js engine and rendering engine; hopefully things will be better with IE8 (though I doubt it will enable it to compete with the others)
October 23rd, 2008 at 4:48 am
Great job! Thanks!
October 23rd, 2008 at 7:44 am
Hello,
I am surprised that you did not try the benchmark with IE8. I do not know if IE8 contains js improvements, did it ? How much ?
IE7 is a 2 years old browser. JIT JavaScript compilation was not on the agenda at this time. Others browsers of this benchmark are no more than 1 year old, it sounds pretty normal to me that they beat IE7.
I hope that each browser will be 5 or 10 times faster than its own 2-years-ago version. It sounds very good for GWT and others js-based applications !
Concerning IE6 and IE7 support : I agree, you cannot do as good with IE6 & IE7 because it was not built for.
I would be also interested by having those results on other OS. May it be different ?
October 23rd, 2008 at 8:08 am
@Samuel I actually did have jit enabled for the FF3.1 tests. The first set of tests I ran I had jit.content only on, I then did another set with jit.content and jit.chrome, which turned out to be slower. Perhaps there is something else I’m doing wrong but I did set the config options correctly.
@Thomas Broyer I agree about the js engine not being the only thing to consider. For the particular operations I’m measuring pretty much the only DOM operation is a single insert of a massive block of html so I think I’m mostly measuring js performance here. Damon talks about this in our google i/o presentation. I’d love faster DOM and CSS support.
@Tanguy Bayard IE8 numbers would be interesting. I didn’t have IE8 installed when I did the measurements though and my main focus was on how the new engines performed. I’ll probably rerun these tests with the next release of our software and I’ll try and include IE8 in the mix then.
November 1st, 2008 at 6:15 am
[...] GWT performance with the latest JavaScript engines [...]
November 21st, 2008 at 8:08 am
Interesting research.
I just wonder what about Opera?
December 19th, 2008 at 4:09 pm
[...] is a follow up to my post about GWT performance with the latest JavaScript engines. In the two months since that I wrote that there have been new releases of many of the browsers I [...]