High-performance GWT. Part 1

This post is the beginning of a series of articles about optimizing and improving the performance of GWT applications. Because of the material I have accumulated quite a lot, decided to split it into 2-3 parts.
Begin to describe what awaits us in the first article.

Reporting issues

In the first part of a series of articles about the optimization of GWT applications, I will discuss the following things:
the

Separation of client code, on-demand loading
getting Rid of the use of heavy classes on the client
resource Caching
a performance Problem with GWT RPC, REST
peculiarities of the influence of layout on the job application
Optimisation of data transferred
using the Scheduler
Using managers for aggregation of requests to the server

Now details about each of these items.

Separation of client code, on-demand loading

In GWT there is a built-in mechanism that allows the developer to "cut" the app apart. Need it primarily for the following purposes:
the

decrease the initial download size
using the principle of lazy loading — the necessary data will be loaded by the application as needed

In order to separate the client code into parts, use the invocation of GWT.runAsync.
An example of using runAsync:

GWT.runAsync(new RunAsyncCallback() {
public void onSuccess() {
new MySettingsDialog().show();
}
public void onFailure(Throwable ohNoes) {
// indicate that something went wrong,
// usually a connectivity or server problem
}
});

The GWT compiler takes the responsibility not only to produce work on the separation of client code, but also to perform as needed to cluster code. It is guaranteed that the separation will be correct. However, separation may not occur. The reason for this can be cross-referenced in the code.
In the presentation of GWT Can Do What with Google I/O, you can see the comparison of download speed of the application before and after cutting it into pieces using runAsync:

Thus, the use of runAsync seriously can reduce initial load time of applications and reduce the number of transmitted client data.
You should pay attention to the AsyncProxy class. Likely its description in the second part of the article, now you can read it in his documentatie.

getting Rid of the use of heavy classes on the client

On the groups page, the Google Web Toolkit can be found discussio about how to reduce the size of the compiled GWT application. Notes in particular the approach to avoid the use of "heavy" classes on the client side, entailing the inclusion of a large amount of code on the client.
First, you can give an example of using the Comparator on the client. Using it entails the inclusion in the client part ~10 KB of code of associated classes.
Using RequestFactory leads to a further increase of the client in the above discussion the client part has increased by 150 KB.
It is also to be careful in case of using external modules — it is possible that their inclusion in the project will entail a significant increase in client side by adding many other classes.

resource Caching

HTTP requests from the client are significant limitations of the client side performance of your application. In case the application will ask separately each resource, a fee for downloading all resources would be great.
To prevent slowing down the client application uses the approach associated with the cached resources.
The advantages of the approach used in a ClientBundle:
the

the resource will be loaded once instead of loading each time as its use
Total volume of stored resources will be smaller

How does the minimization of storage resources in the case of ClientBundle?
Back to the presentation of GWT Can Do What. In it we can see the following illustration:

Thus, the reduced overhead for storing the same data.
As a result, it may decrease the amount of resources?

performance Issues GWT RPC, use REST

GWT RPC is a really handy tool. Providing the interface for organization of client and server code for a service, with support from IDE, it is one of the amazing features build AJAX apps in GWT. However, it is worth considering if it fits you.
The main disadvantages in the case of using GWT RPC might be adding too many redundant data in the request and the complexity of debugging.
As a solution to these problems is possible to note the use of REST. article from Zack Grossbart you can find an example of using REST for GWT projects.
In his article 4 More GWT Anti-patterns highlights the main benefits of REST:
the

REST forces the developer to think about the API. The API may also be provided external services and applications, adding extra convenience and functionality for interaction
Usability testing
Clear separation of client and server

features of the influence of layout on the job application

Very often, the gwt developers are using avtopodstavy layout. Examples that may be used in components height="100%". It is worth saying that сontentHeight, offsetHeight operation heavy. Below are statistics runtime operations offsetHeight in IE, taken from the presentation of the Measure in Milliseconds from Google I/O 2009:

Not only is the result not predictable; its peak value for 18 measurements reached a value of about 85 msec.
A certain time is a total processing resize event. Often, the operation of changing sizes in the case of a forced layout takes time is several times more than a style recalculation.
How can you get rid of this problem? You need to use CSS. Layout is defined using CSS will be rendered much faster by depriving us of the need to call for all DOM hierarchy of components execution heavy techniques such as offsetHeight.
You can use the updated DockPanel that don't use javaScript during resize operation.

It is not recommended to create and store large trees of nested widgets. Widgets have additional overhead that negatively affect memory usage and the size of the client (as a consequence, and speed). The solution is to use HTMLPanel. To track the number of widgets on the pages there is a tool InspectorWidget. About the properties of the plugin can be found on its .

Optimization of transmitted data

Between the client and the server continuously transmits serializable objects. The developer should ask himself whether is passed only the necessary data? Large object graphs, nested subobjects and unnecessary parameter sets take away valuable time and create unnecessary strain. Pass only what you need on the client. Often only what the user sees. All necessary can be obtained, if necessary, in the data. Of course, this approach should not contradict the policy of caching resources on the client side.

using the Scheduler

In GWT there are a mechanism of delayed calls. Previously it was called DeferredCommand, but has been declared deprecated. Now the mechanism is called the Scheduler.
Advantages:
the

does Not block the thread of execution
Gives you the opportunity to first complete all UI events

Quite often the Scheduler used in the later construction of certain objects. However, its proper use is in some cases to do UI application faster due to the longer prioritize UI event.

Using managers for aggregation of requests to the server

Each call to the server imposes a certain delay in the execution. If we have the need to do frequent multiple calls to the server, you can aggregate them in some batch-units.
Starting with version 2.3, GWT has made it possible to use RequestFactory:

requestContext.method1().to(new Receiver<T>(){...});
requestContext.method2().to(new Receiver<T>(){...});
requestContext.fire(new Receiver<Void>(){...}); //called only 1

The advantages of this approach are obvious — greatly reduces the number of calls, and as a result, delay implementation.
If we can cache server responses — you can use caching controllers. To learn about using them by clicking on Silke.

In closing

GWT is a powerful tool that allows you to create perfect cross-browser interface and is widely used outside Google. However, part of the most handy tools impose serious limitations on the performance of the application. It is necessary to carefully optimize the speed of the application to users are also satisfied with it.
In the next article I plan to continue talks about the performance improvements and optimization of GWT applications. In particular, we will discuss how to improve the speed of GWT RPC, JS Shrink, especially the use of native code on the client, the tips to reduce the size of the script; it is also planned to tell about optimization of speed of compilation and to give some tips when the layout of the interface.

Thank you for your attention!

Useful resources:

Article based on information from habrahabr.ru

Поиск по этому блогу

computer express