What should I do to speed up a slow GWT app using MVC

Question

I have changed my app to use MVC and it has gotten pretty slow.

Description:

• The application has a number of 5 composites, each composite represents different data and is not always showing
• The app is using MVC and I am passing the model to each composite when an update occurs.
• I am rebuilding a Tree (and all tree items) every time a notify is recieved, however, only one of the tree items would have changed, so this is possibly a waste.
• Due to the style of the app I have to even notify() for insignificant things like changing the text in a text box or selecting a menu because I have a saved icon that turn to unsaved whenever something is changed in the tree Item.
• All the composites are implementing the same Observer Interface, so all are getting updated on every notify().

Can someone give me some tips on what I should do to speed this app up. Which of the above might be more CPU hungry than others, ie, is rebuilding a Tree with < 20 items on every notify() going to use that much CPU time, do I need to re-design this? Should I create a seperate interface such as SaveStateChanged that will only notify the tree, or is this just a waste of time.

Answer 1

When an application is getting slow, then most time is often not spent performing the JavaScript calculations themselves (eg I don't believe, that just calling a lot of observers is a problem - it depends on what they do!). Very often, slowness is caused by things like redundant layout (eg when each of the observers causes a layout call). Sometimes, lots of DOM manipulations can also be a problem (mainly with Internet Explorer).

I would suggest to play a little bit with Speed Tracer, especially the redundant layout example . If that's not the specific problem in your application, you should be able to take a similar approach as shown in the example to track it down. Use markTimeline("String") to make special parts of your code show up clearly in Speed Tracer's graphs.

Answer 2

The first step you need to take is to isolate exactly where the performance problem is occurring. You've identified some good possible candidates, but you'll want to back that up with cold hard stats.

You may find you only need to address one of the above points, or that there might be another sticking point entirely

Answer 3

I suggest you get rid of the Observer interface in favour of something more finegrained. Look at the MVC architecture in Swing where a JTree is associated with a TreeModel and implements TreeModelListener interface to hear of changes to the model. The TreeModelListener interface has specific methods called by the model to indicate nodes changing, being added or removed from the tree. In addition it has a TreeModelEvent which provides even more data about which nodes are affected. If the model tells you precisely what has changed you will have a lot more scope for reacting intelligently from your listener implementations.