GWT / AJAX Performance Tools

Performance is important in your Web applications, especially in your client code. If you're a GWT user, I wanted to highlight a particularly useful benchmarking library - Jiffy and it's Firebug counterpart. It is the case that Safari's developer tools and Firebug by itself make user-injected benchmarking code less relevant for macro-benchmarks. But, if you're interested in fine-grained measurements and creating a rolling log of them, I found the developer tools a bit lacking.

Benchmarking is really just about specifying two points - a start and a stop. Giving that benchmark a label can be useful, and being able to review logs of these benchmarks over time would also be nice. Jiffy does all of this, with minimal setup time, and if you install the Firebug plugin, very immediate results.

First I downloaded the jiffy.js source and plugged this script tag into the HEAD of my GWT application's main HTML page:

script language="javascript" type="text/javascript" src="jiffy.js"

Then I created this simple class to wrap the required Jiffy calls as Java methods:

public class JiffyUtils {
public native static void mark(String markerName) /*-{
if( $wnd.Jiffy )
 $wnd.Jiffy.mark(markerName);
}-*/;

public native static void measure(String measurementName, String markerName) /*-{
if( $wnd.Jiffy )
 $wnd.Jiffy.measure(measurementName, markerName);
}-*/;
}

...and I was ready to go! I inserted numerous marks and measures into a particularly slow, esoteric series of operations and determined where my bottlenecks were; oddly enough, it lead me to the discovery of the slowness of HashMaps in GWT 1.4 and, to a lesser extent, in 1.5 (Google for "HashMap optimizations gwt" for a bit more info.

Turns out I didn't need continual performance measurements, but Jiffy does offer a bunch of support for it. You can either get a JSON object out of Jiffy with all of your measurements by wrapping a call to

$wnd.Jiffy.getMeasures();

in a JSNI method, which I used momentarily but did not rely upon heavily. You can also use the Jiffy Batch and Realtime logging, which is explained on their site and would be useful for those interested in maintaining backlogs of their performance metrics for analysis.

GWT 1.5 is here!

Just a quick huzzah for the GWT folks ... GWT 1.5 is done! One of the best new features: Java 5 compatibility.

In their own words: 1.5 blog announcement

Enjoy!

GWT and RESTlets

I'm back, with some big news!

RESTlet ported to GWT!

I have been busy with a large-scale, enterprise AJAX Web application, and I'm happy to say I've had to write at most 200 lines of Javascript; instead, we have about 80,000 lines of Java. Most of you probably know why ... we're using Google Web Toolkit (GWT) (+ RESTlets), and thought I would share my love for these libraries. (Before we delve deep into my ramblings, I'd like to point out there other libraries that rival RESTlet's fantastic-ness, such as Jersey, but I've not used them extensively enough to write about them, so feel free to post your links to other blogs!)

If you haven't heard of GWT or just haven't taken the time to check it out, you really, really should [ http://code.google.com/p/googlewebtoolkit/ ]. In short, Google developed a compiler that creates Javascript bytecode from Java source, so you develop your Client-side code just as if you're developing a Java app (don't worry, custom Javascript can be invoked using JSNI), and Google does the rest of the work.

If you're going to build both the client-side and server-side bits, GWT has some built-in support for you. It provides RPC mechanisms, as well as ways to make plain ol' HTTP requests. First up: RPC! Simply explained, an RPC-based application is built using just a few pieces and parts - an interface so the client knows what methods it can invoke and an implementation of these methods on the server. Having used it, though, the RPC is a bit arduous to maintain, clunky to build, and can be slow as molasses. But it works, has the benefit of making the client-side code easy to read, and methods more intuitive to invoke.

Now, if you want to provide server-side functionality via HTTP requests instead of RPC calls, the RequestBuilder class is what you want. It has a simple and relatively robust API, but has its drawbacks. If I had to try to pick a fight, I'd say the drawbacks are that it does require a bit of knowledge about the lower-level workings of HTTP requests (e.g. header syntax), and doesn't provide a quick way to get XML from the Response object in a Document format, but there aren't any really pressing issues that I've encountered.

So enough about GWT - what is this RESTlet stuff? Well, it's based on a particular architectural style, developed in the wonderful world of Acadaemia (don't run away now): Representational State Transfer (REST). It's just a way of designing how to manage and access resources, and once you figure it out, you'll notice a lot of the Internet basically works this way already. Let's say you're building a store that sells T-shirts of many colors. A RESTful way of modelling your store-front would be to provide the resources of your store, e.g. the T-shirts, in a representational way. So to see a representation of all T-shirts sold at the store, one might visit the url http://www.tshirtstore.com/storefront/tshirts. To see a representation of all blue T-shirts, one could visit /storefront/tshirts/blue. To visit the cart, one could go to /storefront/cart. These resources can be delivered as XML, XHTML, JSON, binary, plain-text ... you name it. Each URL basically represents a resource and ways to get to other resources, if applicable. Intuitive? I tend to think so.

By the by, my colleague explains it well (i.e. better) in non-example-based terminology, if you'd like to see it go here: http://gogocarl.blogspot.com/

In any case, REST is a wonderful way to expose resources and functionality to your client code in an intuitive way, and the greatest of all is that it highly decouples your client and server code bases, so if you deliver your resources in a client-independent way (e.g. XML), you can show off your resources in many different ways.

If you'd like to create a GWT + RESTlet application, check out the RESTlet-GWT module [ http://blog.noelios.com/2008/07/25/restlet-ported-to-gwt/ ]. If you give it a try let me know how it goes! I've had such good luck with it I'm rather skewed towards it, but I'm still a bit of a n3wb Web app developer, and I'd be very interested to know what your opinions are.