Re: GWT performance optimization singleton classes, RPC types, server round-trips

Thank you Thomas.
I should probably start thinking about changing my button singletons to instantiate them on-demand and discard on detach. Regarding the selection of correct permutation on the server, given the caveats, I may leave this until I become too eager and if I do I will get back to you with the results. regards

On Tuesday, December 18, 2012 10:47:01 AM UTC, Thomas Broyer wrote:

On Tuesday, December 18, 2012 10:54:06 AM UTC+1, s3cure wrote:

Using GWT 2.5, I am currently going through performance optimizations of a reasonable size GWT client application which is served by C# .NET RPC interfaces on the server side. I have been through the Google I/O video and we have made significant impovements by reducing number of widgets and third party library dependencies, introducing split points and reducing round trips etc. There are a few area that I am not sure of that I would like your views on.

1. I have a buttons toolbar (using our custom button which extends GWT Button) which is frequently redrawn based on the state of the aplication and there are about 150 buttons to select from to add/remove to the toolbar. Currently I have a singleton class per button which extends my custom base button class. How does this translates into JS and whether using singleton classes like this have any impact on the application size and performance? What happens when a singleton button is removed from parent and re-added? Would it stay in memory from the first instantiation for the life time of the app?

It's a singleton, so yes it's kept alive until you leave the app.

 

2. As I am using .NET on the server side, I am using a simple open source third-party JSON-RPC library to make calls to the server. Is there any thing I can do for example exclude GWT-RPC implementation from the JS to reduce the size? Would blacklisting *.* make any difference?

If you don't use GWT-RPC you shouldn't have anything related to GWT-RPC in the generated JS.

 

3. One of the things mentioned in the GWT performance videos was to determine the user-agent on the server and dispatch the appropriate JS to avoid a round trip. However I can not figure out how to compile the application so that I can know which .cache JS file belongs to which browser implemntation unless I compile it for each user-agent one at a time?

The xsiframe linker generates a compilation-mappings.txt which you can read on the server-side to generate the appropriate HTML host page (that's assuming all deferred binding properties can be resolved server-side; if you can't, I suppose you'll have to collapse their values: strong permutations are those selected on the server-side, and soft permutations are selected at runtime; see https://code.google.com/p/google-web-toolkit/wiki/SoftPermutations)

The problem then is to "install" the selected permutation. I believe you'll have to use CrossSiteIframeLinker and <set-configuration-property name="installScriptJs"> to use installScriptAlreadyIncluded.js instead of installScriptEarlyDownload.js.

Looking at Google Groups, it seems like they're using a variation of CrossSiteIframeLinker where all permutations include the bootstrap code from the selection script. At first glance, I'd say they extended CrossSiteIframeLinker to override shouldIncludeBootstrapInPrimaryFragment to return 'true' (see also the javadoc for this method).

I've never tried those approaches, so if you do, can you please get back to me? (to tell me if you succeeded, if I missed something, etc.)

--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/b0AH1s1pPeIJ.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to google-web-toolkit+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.