Google Web Toolkit JavaScript Vs hand Crafted JavaScript benchmark
Is JavaScript Generated by Google Web ToolKit faster or slower than hand crafted Javascript?
In short there is no difference, but there is more to the story than that. Below are my findings, and I present them to you in a non-biased fashion and with no guarantee. This benchmark is un-comprehensive and so you will have to forgive me for possible errors. The benchmark has been run on Ubuntu 10.04 and Mac OS X 10.6 using FireFox, Chrome and Safari. It was also tested on the iPhone in Safari the Macintosh browser. (Part Two of the article is here Google Web Toolkit JavaScript Vs hand Crafted JavaScript benchmark Part 2) (Thanks to @Carl)
I have used a sorting algorithm known as the bubble sort algorithm to benchmark the speed of both scripts and reproduced the same code in both Java (Google Web Toolkit) and JavaScript. Both pieces of code are almost identical but for the few syntax differences, to make this test as fair as possible. Each script is given the same array of numbers to sort, timers are setup to clock how long it takes to execute the sort() method in each case. Both scripts are then run 10 times to get the average time of execution. Below are the charted benchmark results where Google Web ToolKit generated JavaScript is green and handcrafted JavaScript red.
Benchmark Results
Click image to enlarge
Benchmark Conclusions
Well, as can be seen from the graph, there are some very positive results for browsers such as Chrome and Safari. Though (as expected) running both pieces of code in Firefox is extremely slow, due to the JavaScript engine used in the browser. However, with reports of a new webkit based JavaScript engine being developed for Firefox we should hopefully see some well needed improvement.
Safari on the iPhone shows some interesting results where GWT is faster than the handcrafted JavaScript. Now those results are not comprehensive as the version number of Safari is unknown, but it’s presumably an old version. Also the test was run on an iPhone emulator that comes with the Mac OS X development tools and iPhone SDK, though from what I understand it’s as good as the real thing.
I will be following up this article in the next week or two with benchmark results from Windows xp, Vista, 7, Symbian OS, and also Android as I am soon to be the proud owner of an Android aPad tablet device from Amazon. Hopefully it’ll be delivered before I move back down to Carlow.
(Part Two of the article is here Google Web Toolkit JavaScript Vs hand Crafted JavaScript benchmark Part 2)
Thanks for reading!
Benchmark screencast
About the Author
Ciarán McCann
Flax Project Founder - Ciarán McCann is an extremely passionate and motivated programmer who has been programming for about 4 years now. Currently attending Carlow I.T studying computer games development. He has experience in many different programming languages, markup languages and general technologies. His role in the Flax Project is as a blogger/Web Designer and Flax Engine programmer. Please excuse any bad grammar/spelling, I am a bit on the Dyslexic side. Follow me on Twitter for info on what I am working on.
Related Posts
-
Flax HTML5 Game Engine Development Diary Part 11
Well it’s that time again, it’s been just about three weeks since the first iteration of the Flax HTML5 Game Engine 0.1 and as promised […]
Flax HTML5 Game Engine Development Diary Part 10
Well, it’s been a while, hasn’t it? In the time since the last dev diary, we’ve gotten jobs, passed exams (and gotten into the third […]
19 Comments
Trackbacks for this post
-
[…] Pełny artykuł na: Google Web Toolkit JavaScript Vs hand Crafted JavaScript benchmark … […]
-
[…] out it’s not too bad. Ciaran McCann did some tests and found out only FireFox had some serious troubles running the GWT code. The test isn’t […]
-
[…] for those of you who read the first post about benchmarking GWT vs JavaScript Part 1 on Linux, Mac, iPhone and a varity of browsers here is the continuation of that article tested on […]
It’s a bit surprising the Windows platform is missing from the tests, which has the biggest share among users.
Agreed. The problem is that neither of us have a Windows machine to test this on. 😉
Yes true, I will follow that up next week. Its just I currently don’t have access to a computer running windows which is up to date. Thanks for your comment
Then != than. Cannot forgive that.
My apologies, fixed. 🙂
Figured why my gmail locks out my firefox sometimes…
You are not really testing the problem GWT addresses which have to do more with developer productivity and io latency.
Hi Steve
No your right I am not, the benchmark wasn’t intended to test that.
Only the execution time of the code. Thanks for your comment.
Hi Ciáran,
Have you performed the tests in Firefox by disabling Firebug?
Firebug has some impact on JavaScript performance.
Hi piouPiouM,
No I never thought about that actually. I will redo the Ubuntu, Mac results with it disabled next week when I am testing Windows, Android and symbian os.
Thanks for the comment.
Interresting but not surprising because GWT generate Javascript anyway and that typically the type of code that will be fairly similar be it code in java and compiled to GWT or hand crafted javascript.
But GWT is not about that. GWT is more about managing big bunch of javascript code, having a full GUI in javascript. All coded in JAVA, debugged with you JAVA IDE, and with many productivity and optimisations related to web site :
– same JAVA code but a compiled code optimised for each browser.
– management of browser cache, image sprite and all.
– reduction of javascript code size.
– i18n at compile time.
– asynchronous loading of javascript code. (so you don’t download all at startup).
– if you have a JAVA backend, same java object can be used on client and server and some code too.
– exposure of backend service has RPC (using internally XmlHttpRequest).
– removing of unused code
– using Junit without browser etc for most part of the web app testing, including client code.
– use all of your Java facilities like refactoring.
Hi Nicolas,
I would agree with you GWT is not about that, its main aim is AJAX and all the above you have stated.Though our interest in GWT is for the ability to create JavaScript from Java.
Thanks for your comment.
The follow on to this article, is posted here http://flax.ie/google-web-toolkit-javascript-vs-hand-crafted-javascript-benchmark-part-2/
Since GWT generates javascript and you are benchmarking it against javascript you’ve written, isn’t what you are really testing is if you can write javascript that is faster then what the google engineers could write? Or even more accurate, what google engineers could generate with java code they’ve written?
GWT is interesting because its use case is based on the strengths of the people using it. If you are a great javascript hacker, you will probably hate GWT, whereas if you are a Java guru mystified by that UI stuff, you will love GWT to pieces.
The real question is, is GWT performant and flexible enough for a Java Developer to use instead of having to write everything by hand? If is performant enough, then getting speed improvements via hand coding is probably not worth the productivity loss of a java engineer just to gain potential speed benefits that probably won’t be realized because the java engineer doesn’t know javascript well enough to get them anway. Then, is it flexible enough to create the features needed on the project?
If it is performant enough and flexible enough, isn’t that enough?
Yes the benchmark is exactly that. For me I know very little JavaScript so I love the option that GWT provides, but it also has other benefits such as the server side RPC and it focus on reducing latency. Also the JavaScript Native Interface which GWT provides makes it possible to integrate existing JavaScript Library such as the GWT EXT library. I really think its a great technology.
Thanks for your comment Josh.
I think the interesting part of a test maybe the benchmark of the method call performance, because if I remember right there is a huge hack in GWT to simulate Java like obejct orientation.
The code in this benchmark can be translated to JavaScript nearly as is.