High Performance GXT / GWT Applications: Coding Java for JavaScript

It's been some time, so I thought I would try and post another informative blog.

I thought my second blog would involve detailing the trouble points and steps involved in migrating between Gwt-Ext and GXT, however, it’s now been such a long time that I can no longer remember what the trouble points were except for a few:

1. The Portal class: the way the columns are defined and the way you interact with the contents of those columns is considerably different. In Gwt-Ext you would instantiate your PortalColumn class and do all the setup with this, in GXT the Portal class itself has all the methods you require.
2. Listeners and Events: Gwt-Ext was very tightly type-cast which made working out which listener to use and which events to raise incredibly easy. Actually, it was more than easy, you had to use a specific setter method for a specific type of listener so nothing could ever go wrong! In GXT the use of generics is taken to the next level (sometimes a bit excessively) and most classes will not have methods such as addClickListener() or addMouseListener(), instead they will all have addListener(). Some classes do have more tightly type-cast listeners (ListStore for example has an addStoreListener() method), but generally speaking generics are the rule of thumb which can be a pain initially.
3. XmlReader / JsonReader: these do not support nested items in GXT. Hopefully this will change. In the mean time it’s easy enough to extend these classes to handle this for you.

If I have an epiphany I will come back and write something a bit more extensive on migration but for the time being it will have to wait. Having said this, we can now move onto a new hot topic: Coding Java for JavaScript!

GWT has provided us with a magical tool to work with which allows developers to code in Java and turn that into highly compact and optimised JavaScript. This is a great idea, now all Java developers can develop web pages, but, there is one flaw: JavaScript is not Java. This should come as no surprise to most of you but what may be a surprise are some of the performance impacts caused by developing JavaScript like it were Java.

I will only pick on a couple of these items for now and focus primarily on improving GXT’s performance. Note that the underlying principles of the following items can be applied to standard GWT:

• Objects: Creating objects in JavaScript is expensive. This will cause the page to take time to render and potentially freeze for a few moments depending on how old your PC is or whether you are running an old browser like Internet Explorer 6.

• Hash maps: They are slow. Forget slow, they are sluggish. See this post by the guys at Lombardi for some actual figures: http://development.lombardi.com/?p=95. The good thing is that the guys at Lombardi don’t just provide us with figures, they also provide us with a solution: FastStringMap.

• Events and Listeners: Attaching events and listening for these is another expensive activity. This can quickly become very slow as you create and attach multiple events and listeners to different items on your page.

Note that some of the points above are alleviated by new browser technologies (multi-threaded JavaScript and Chrome spring to mind!) but if you are a respectable developer, or better, a developer who wants maximum adoption for their site – then cross browser compatibility is not optional.

So, let’s get onto the topics above and explain how the performance can be improved!

Objects

This is one which can be explained relatively quickly: keep the objects you need to the minimum possible. In most cases the wonderful GWT compiler will take care of removing the objects and actually putting your code inline which will already give you improved performance. However, there are times when you can’t rely solely on the compiler and keeping in the back of your mind that less objects equals more performance is a must. So, unless it’s strictly necessary or unless your code looks like a big mess without them, keep objects to a minimum when possible.

This can prove difficult when using GXTs XML and JSON readers as they create Lists of objects (ModelData). On top of this, all the ModelData objects are based on HashMaps which adds an even greater burden! So, to minimise the pain, we can continue to use the objects but make them faster by removing the HashMaps which brings us onto our next topic: HashMaps.

HashMaps

Slow, slow, slow. Not a perfect English sentence, but it gets the point across! HashMaps are generally very useful, unfortunately these are also very slow in JavaScript. Luckily, the guys at Google have come to the rescue once again giving us the wonderfully fast FastStringMap. You can find more details on this topic here: http://development.lombardi.com/?p=95.

Now, how can we use this information to increase the performance of GXT?

As I mentioned above, all the ModelData objects are based on HashMaps, so in order to increase performance we need to create our own subset of ModelData objects and replace the HashMaps with FastStringMaps.

The first thing to do is subclass the FastStringMap to allow public access to this class (alternatively you can copy this class into your package structure to achieve the same results). The reason for doing this is that Google have unfortunately made this class private! The location of the FastStringMap is:

com.google.gwt.user.client.ui

Once you’ve done this, you need to create your own copies of BaseModel and BaseModelData (note you can also extend the BeanModel and any other model you may need to use, we only extended the model’s above as those were the only ones we needed). We created two new classes called FastBaseModel and FastBaseModelData. Note that the BaseModelData class is more compact as it doesn’t listen for changes to the data so use this class unless you really need the features offered by the BaseModel class or the BeanModel class.

The FastBaseModel and FastBaseModelData are replicas of their original classes except for the fact that they use FastStringMaps rather than HashMaps.

Once you've made these changes, you now need to ensure that you XmlReaders and JsonReaders actually use these objects. In order to do this, extend the two readers (we called them FastXmlReader and FastJsonReader) and override the newModelInstance() methods to return the FastBaseModelData objects:

  protected ModelData newModelInstance() {
    return new FastBaseModelData();
  }

That’s it. You now have super fast readers and data objects. This alone will prove to be quite a performance improvement, especially when you are reading large data sets. The primary difference you will notice is that when large data sets are read, there will no longer be a pause between the download of the data – the reading of the data – and the displaying of the data.

Note that if you are using JsonTreeReader, you can make the same changes there to get the performance enhancements.

Events and Listeners

Last but not least... Events and Listeners. Unfortunately these are quite heavily used throughout GXT and there is little we can do about that. However, there are times when we can make the most of these. I like to revert back to standard GWT and assign browser event listeners (onMouseClick, onClick, etc) to the parent container and let them cascade down to the children. In most cases (unless the class you are using really needs the events) you can then cancel the bubble and stop the event on your overall listener which will improve performance by avoiding hundreds of listeners being fired up!

In your overall listener you can then identify the component which was selected and route accordingly or better, you can have methods to handle the events in the relevant objects and all you do is call these methods from your listener. For example:

GWT.sinkEvents(parent.getElement(), MyListOfEvents);
GWT.setEventListener(parent.getElement(), new EventListener() {
public void onBrowserEvent(Event event) {
if(event = onClick) {
for(myObjects)
		myObject.clickHandler();
}
}
});

This is pseudo code but it should give you the general idea. This will then delegate the handling of the event to the relevant object rather than having to sieve or hardcode the elements into the parent class.

Conclusion

These are just some of the things which can be done to improve performance. The most noticeable one will be the HashMap changes (you can actually see the difference in behaviour when your data is loaded) but don’t forget to keep the other factors in the back of your mind as they WILL improve your performance.

I have now ran out of things to say, so for now, peace out. Oh, and if you have any other performance enhancements or items you recon are worth mentioning on this topic, please do leave comments!

We used all the enhancements above to make our first product SambaJAM. Even so we are continously working to improve performance. I'm looking to write an article on this which will include injecting HTML straight into the page and subsequently attaching listeners. In the mean time, if you wish to see what all this looks like as an application rather than snippets of code, feel free to join the Beta program.

We are not going to distribute the information you provide when joining the Beta, but SambaJam works on an invite only basis, so we use your details to invite you into SambaJam. You can then use it as much as you like and as often as you like to share documents, organise your calendar, create wiki's, discussion forums and easily invite other people to work with you. 

You should see a box with the form on the right hand side which you can fill in. 

If the form is not there, click here to see the form: