With Google Web Toolkit (GWT), you write your
AJAXfront-end in the Java programming language which
…claims Google. And I must say, I’m pretty impressed by the ease of development
There are a couple of caveats, however:
- The set of supported Java classes is limited, which sometimes causes confusion. For instance, there is a
Characterclass, but the
isWhitespace()method is not supported. And neither is
- Serialization works differently from the Java standard.
- You can’t work with regular
W3C DOMobjects on the client. Instead,
GWTprovides it’s own
- Even though Google claims that
The purpose of this post is to elaborate on that last point.
Most developers evolve a sense of intuition about what type of code can be a performance problem, and what not. The problem with
Therefore, your usual rules of thumb won’t work in
GWT development. Here’s a couple that may.
Serialization is slow
Our application created a domain model on the server, serialized that to the client, and had the client render it. The problem was that the model could become quite large, consisting of thousands of objects. This is not something that
GWT currently handles well. Serialization performance appears to be proportional to the number of objects, not just to their total size. Therefore, we translated the model to
XML, and serialized that as a single string. This was way faster.
However, this meant that we needed to parse the
XML on the client side to reconstruct our model.
GWT provides an
XMLParser class to handle just that. This class is very efficient in parsing
XML, but it turned out that traversing the resulting
DOM document was still too slow.
So I wrote a dedicated
XML parser, one that can only parse the subset of
XML documents that represent our domain model. This parser builds the domain model directly, without intermediate representation. This proved to be faster than the generic approach, but only after being very careful with handling strings.
Some string handling is slow, particularly in Internet Explorer
Java developers know that string handling can be a performance bottleneck. This is also true for
GWT development, but not in quite the same way. For instance, using
StringBuilder is usually sufficient for improving
StringBuffer.append() can be very slow on Internet Explorer, for instance.
GWT 1.6 will contain its own version of
StringBuffer that will alleviate some of these problems. Since 1.6 isn’t released yet, we just copied this class into our project.
But even with the new
StringBuffer class, you still need to be careful when dealing with strings. Some of the
StringBuffer methods are implemented by calling
toString() and doing something on the result. That can be a real performance killer. So anything you can do to stay away from
charAt(), etc. will help you. This can mean that it’s sometimes better to work with plain
Strings instead of
The downside of these is that they translate any widgets you insert into the table to
HTML, and you loose all the functionality to attached to them, like click handling. Instead, you can add a
TableListener, that has a
Varargs are slow
Don’t trust rules of thumb, use a profiler
The problem with rules of thumb is that they are just that: principles with broad application that are not intended to be strictly accurate or reliable for every situation. You shouldn’t put all your trust in them, but measure where the pain really is. This means using a profiler.
Performance in different browsers
The only problem with Firebug is that it’s a FireFox plugin, and therefore not available for Internet Explorer. [Firebug Lite doesn’t contain a profiler.] Not that I personally would want to use IE, but our customers do, unfortunately.
Internet Explorer 8 will supposedly be better:
We have made huge improvements to widely-used JScript functionality including faster string, array, and lookup operations.
We’ll have to see how that works out when IE8 is released…
BTW, if you’re interested in browser performance, check out this comparison.