Urgent help with GWT dev mode performance required

[joerg.h...@googlemail.com]

We have created a large application based on GWT (and SmartGWT). The more the application has grown the longer it takes to start the dev mode or to refresh a page in the browser.

I have read a lot of posts in the web about this problem, like e.g. this one:

http://blog.trifork.nl/2007/11/30/optimizing-startup-time-for-gwt-hosted-mode/

However currently it takes almost 10 minutes to startup the enitre setup and beeing able to do some tests. A refresh takes about 2-3 minutes. This is more than slow or in other words in-acceptable  The benefit of GWT is maintenance of large applications and except for this problem it does a perfect job. The GWT developers have really done an excellent job in hiding the browser hell from the java programmer. Thanks!

So what are we doing wrong. First of all some details about our architecture:

1. We are using GWTP and therefore GIN. While I personally think that the MVP approach is more academic as if something changes in a dialog you have to both change presenter and view so the separation of these two with interfaces etc. is often more in the way than a real help. However, GWTP does a great job for history management (back button, bookmarking dialog state), for composition of dialogs using slots and for code-splitting. With this learning we only use presenters for the main dialogs but do not use GWTP for subdialogs but created our own layer for that. However for > 100 dialoges all presenter proxies need to be rebound. However each of them is very fast. In total ~15 seconds.

2. We are using GWT-RPC and we have ~100 Services. As the actual approach of GWT with Async-Interfaces was not suitable for this scale from our point of view. From Google I/O I heard of a great concept of having a single generic RPC service that can adopt any logical service. I have reimplemnted this as Open-Source-Project if someone whats to understand this in detail:

https://github.com/m-m-m/mmm/tree/master/mmm-service/mmm-service-impl-gwt

The main idea is to have a marker interface for services and use a rebinding generator to generate a stub for each service that collects the arguments and puts them in a serializable object. This approach also allows bundling multiple service calls in one physical HTTP request with 1-2 lines of code.

In our large project we already did some optimizations to avoid having Serializable as type of the service arguments. Still rebinding for this already takes one minute.

3. We are using SmartGWT. I do not like this decision for arbitrary reasons but however it has really great widgets where plain GWT is way to low level.

4. We need a way to show our business objects received in the client in list grids. Due to a strange design of SmartGWT and the lack of reflection in GWT this was not so easy. We solved this with another rebinding generator that automatically converts our business objects into the required structure of SmartGWT (ListGridRecord). However rebinding of this again takes ~30 more seconds.

5. We are using the i18n messages feature of GWT. As we have a modular system build out of 7 subsystems we have 14 *Messages (one for errors and one for texts) interfaces that need to be rebound. Another ~8 seconds.

6. We also use springframework and have a set of server side components that take another 10-15 seconds to startup. We already have a separate tomcat with all the persistence logic so our GWT client is a separate webapp with a serverside that only delegates to the tomcat backend. This already speeds up development and doing changes in the backend is fast and smooth.

The total amount of delay appears to be a large sum of multiple pieces. I still need to investigate and analyze in more detail.

It already takes a minute before I get the launch URL

The most extreme thing is however when I open the URL in the browser and have to wait a long time until I get something like this:

[TRACE] [portal] - Found 6727 cached units.  Used 6727 / 6741 units from cache.

Often it says Found 0 cached units. Then I have to wait 1-2 Minutes until the next trace log message appears.

***

My main question is simple: Why is there no way to tell GWT to reuse rebinding results, etc. instead of doing everything from scratch all the time?

Of course one could remove all code from the entry point and put a totally different client inside so the behavior is fine as default. But if I change a single line of code

and need to refresh the current dialog to test this change, why the heck do I need the CompilingClassLoader to regenerate my entire application from scratch.

I digged into GWT and found that there is a CLI option -XenableGeneratorResultCaching what seems to be what I am looking for. However I failed in using it properly

or it is not completely implemented as it appeared to me from digging into GeneratorExtWrapper. I also patched this class with no luck...

Is there anybody who can give me a hint with this? Are there any new features in 2.5 that could help me or something planned for future releases?

A little optimization I could add is creating a development dialog that allows to reset all views so if a dialog is reopened the view is recreated. This helps for changes that get hot-synced by GWT. However most changes are not and require a fresh start of GWT dev mode (10 minutes).

Ideally I would also need a way to prevent regeneration after fresh start.

Maybe I have to kick out all GWT-Generators and replace them with real java code generator that are invoked only when the input changes.

Any hints to speed up the development time is very welcome.

Cheers

  Jörg

[Jens]

2-3 minutes really hurts! How large is your app? We have about 150k LOC and a refresh in Firefox takes ~5 seconds. As DevMode with Firefox seems to be leaking memory sometimes I have configured DevMode to use 1,5G heap space and 1G permgen space. Our app uses GWT-RPC (single service with lots of commands), UiBinder, GIN, ClientBundles, SafeHtmlTemplates. 

In GWT 2.5 the GeneratorExt has been renamed to IncrementalGenerator and its not experimental anymore. In order to speed up SuperDevMode you should expect that most GWT generators will be changed to IncrementalGenerator so that they do not regenerate everything from scratch (RPC and ClientBundle generator are already IncrementalGenerators). 

Of course all your 3rd party generators also need to be changed and this could take a while (haven't found any documentation how to implement an IncrementalGenerator). Especially GIN can hurt I think as it references quite a lot of classes in your app.

Also using a lot JSNI code can hurt DevMode performance as the Plugin always has to translate between Java and Javascript. Not sure if SmartGWT is implemented in GWT or if its just a wrapper for a native JS library.

So currently your best bet is to hope on GWT 2.6 which is said to concentrate on performance issues and in the mean time modularize your GWT application into smaller GWT modules. Then you can create development entry points that only inherit a subset of your GWT modules for a given feature. That way you can develop "Feature A" and your FeatureA-EntryPoint would only reference code thats relevant to "Feature A" (along with your apps infrastructure code). Reducing the code makes DevMode a lot faster!

-- J.

[joerg.h...@googlemail.com]

Hi Jens,

thanks for your feedback. The memory leak is also what we discovered. You can see that with -verbose:gc,

We are in the progress of migrating to x64 and adding lots of RAM. Your hints give some hope that this will help.

So far we can only use 3,5 GB RAM what is too little. We already have SSDs on Lenovo T410 what should be fine.

Regular java dev rocks on that laptops...

Also upgrading to GWT 2.5 will be next on our roadmap. Hopefully this will not break our app.

We also have already modularized our app but however each module provides reusable sub-dialog components so in the end we need everything together for most of the things. Maybe a different business design would help but regulary the technology should follow the business and not vice versa...

I also forgot to mention that we had to integrate GIS using gwt open layers that is also a quite heavy load.

I will try to change the design so we can opt this out.

Further we have gwt-log that adds another service but this should not hurt...

Thanks

  Jörg