The postings on this site are the contributor's and don’t necessarily represent IBM’s positions, strategies or opinions.
September 5th, 2008 Damon Lundin Posted in GWT | 6 Comments »
After much anticipation, the Google Web Toolkit version 1.5 has been officially released. The most significant feature of this release is support for Java 1.5 but there have also been optimizations made to the GWT compiler that should make GWT applications faster automatically. We on the Blueprint team have just made the upgrade and we expect our next release will use GWT 1.5. I took a few minutes to gather some performance data for IE6 (our slowest supported platform) on the upgrade to see just what we get out of 1.5.
These are apples-to-apples comparisons; I ran the tests against our app running with GWT 1.4, restarted the server with GWT 1.5 and tried again. The only differences in our code between the 1.4 and 1.5 tests were the changes necessary to do the migration which included a couple of fixes, adding generics to our RPC interfaces and converting longs to doubles.
My first test was rather unsettling since it appeared that 1.5 was making our application slower. At that point, I had been running against Javascript code compiled with the DETAILED setting and hadn’t converted the longs to doubles yet. I rebuilt with OBF and that made a significant difference. I don’t know if there are optimizations that only run for OBF generated code but I suspect the size difference in the generated code between 1.4 and 1.5 played a big role. The size of the generated OBF code is a bit bigger for 1.5 and while I didn’t look at the DETAILED size, I imagine the gap would be even larger and that would weigh down the page load time.
I was also surprised that converting longs to doubles made as big of an impact as it did. We don’t have many usages of longs. Most of them are a couple dozen timer instrumentation points but converting them made a noticeable difference. The long emulation must be particularly slow.
I ran two tests on two different very large business processes. The first test was the loading of our Map view. This view covers the loading of the HTML page, loading of the initial data from JSON and the creation of a large number of GWT widgets and listeners. The second test was switching to our Diagram view; this is what I discussed in my presentation at Google I/O. This view does not use any widgets and is very light as far as using GWT goes; it’s mostly pure Java code. It generates raw HTML and executes our line layout and routing algorithm. I expected an improvement in the Map view (lots of GWT stuff) but not much on the Diagram view (not much GWT stuff).
Here are the numbers from 1.4 -> 1.5.
Process 1 Map: 5969ms -> 5368ms (-10%)
Process 1 Diagram: 2924ms -> 2824ms (-3%)
Process 2 Map: 5418ms -> 4667ms (-14%)
Process 2 Diagram: 5538ms -> 5007ms (-10%)
I would say that this shows we’re getting around a 10% reduction in time with a simple upgrade from GWT 1.4 to 1.5 and even an improvement on the Diagram. This is a simple win as far as we’re concerned.
I got a very rough estimate of the number of widgets created during the page loading for Process 1 and the number comes out to around 1600 individual widgets (including individual panels) but not counting every JSO (which is probably a very large number).
The GWT compile time increased pretty dramatically from 55 seconds to 321 seconds which is almost six times longer. I’m more than happy with the tradeoff between this and the new features we get with 1.5.
The generated OBF code increased in size. We went from 673,876 bytes to 748,574 bytes (+11%) in uncompressed size on our largest module. The total application is about 36,000 lines of GWT compiled code (excluding comments and whitespace) and that doesn’t include double counting lines that are reused in multiple modules.
I’m not sure when we’ll get to it, but we plan some more extensive changes to our code to take advantage of the 1.5 features. One of those is to replace or update the use of JSON embedded in the HTML page. At the moment, our core data objects are native JSOs because converting them to GWT/Java objects was too expensive (lots of extra JSO creation). This results in an unpleasant dual hierarchy between JSO and Java objects. We can deal with that by using GWT’s new JSO overlay functionality. I’m also going to take a shot at using the GWT serialization mechanism instead of JSON and see how that comes out (it would probably be slower than an “eval” which is basically what we’ve got now, but the String intern optimization might make up for that).
If you want to learn more about our experiences with GWT or how to write a high performance GWT application, you can view our presentation at the recent Google I/O conference: http://sites.google.com/site/io/using-gwt-to-build-a-high-performance-collaborative-diagramming-tool
September 5th, 2008 at 7:45 pm
[...] Posted on September 5, 2008 by Tim good folks at Lombardi Software’s Blueprint team posted their review of the migration to GWT 1.5 and what it means to performance of their project. Here are some [...]
September 8th, 2008 at 10:29 am
I’ve just done a bit of performance testing of JSON (overlay types) vs GWT-RPC and found that though RPC de-serialization is nearly twice as fast as the old JSON parser, it is still not as fast as using an overlay type and directly evaluating the JSON.
The datasets that I used showed that the RPC payload was about 1/3 the size of the JSON, but that the RPC de-serialization took about 1.5 times as long.
My payloads (embedded in the host page) were 180K for JSON and 68K for RPC. the payloads were for identical object graphs.
and the de-serialization times were:
20ms (JSON eval)
35ms (RPC)
These test were performed with the RPC/JSON payload embedded in the host page to make it easier to isolate and profile the de-serialization bits.
hopefully some of this info is useful as you continue to optimize Blueprint.
-jason
September 8th, 2008 at 5:15 pm
That’s interesting info Jason. Did you take into account that the page with the RPC data might download faster to the client given it’s smaller size?
I tried at one point to write code to convert the JSON objects into GWT/Java objects so we wouldn’t have to mess with the native JSOs. I used the nasty GWT JSON parser and didn’t try to find a way to do it faster and it was ridiculously slow (like 30 times slower) so we decided to hold off on trying anything else.
However, using the RPC mechanism you tried shows a difference of only 15ms with quite a lot of data. That’s a trivial amount of time (and generally within the margin of error for such a measurement). If this difference is really that small, I would consider it acceptable.
The only reason I’m considering using the RPC mechanism instead of overlay types is that there are no restrictions on the serialized objects unlike the overlay types which do have restrictions (no subclasses for one). I haven’t gotten into it yet to know the tradeoffs between the overlay and regular objects.
September 9th, 2008 at 3:14 pm
I didn’t profile the data transfer part, as that is really dependent upon the network. Obviously a smaller payload will give better transfer speeds than a larger one on a given connection though. And depending upon the connection, I suppose that difference could end up being nontrivial especially with larger payloads.
True, 15ms isn’t really that significant a difference. I didn’t try larger payloads so I don’t know if those numbers begin to diverge. In my case I was looking to optimize an existing JSON implementation, and the numbers seemed to indicate that simply updating the client side JSON parsing to direct eval would give a pretty significant improvement.
One other thing I didn’t take into consideration was the complication of the object graph. in my case, there were something on the order of 300 objects, each containing array fields and embedded objects being de-serialized, but a simpler graph (say a single object with rather large string fields) could have the same payload size, but would possibly de-serialize much quicker (just guessing).
There certainly are advantages to RPC’s ability to use POJOs on both the server and client, and with the possibility of RPC gaining the ability to directly evaluate the payload on the client ( http://code.google.com/p/google-web-toolkit/wiki/RpcDirectEval ) the de-serialization performance could possibly end up more inline with JSON using overlay types.
It may be worth commenting about Bob’s de-RPC proposal (there’s a thread on GWT-C) with any special case scenarios that you might run into in Blueprint. Particularly the possibility of increased bandwidth vs decreased de-serialization time.
-jason
October 13th, 2008 at 3:59 pm
[...] that is developed by the great folks at Google, and as evidenced by our relatively painless upgrade to its 1.5 release GWT is well on its way to become a mature technology. The quality of GWT, as well as its open [...]
January 27th, 2009 at 4:35 am
Nice work! I’ll have to do a cross post on this one