Article: GWT: Improving performance

[Alexey Kharlamov]

Hello All!

During development of our last GWT based application we have
experienced some problems with rendering performance. Now they are
resolved. So we would like to share our experience with community and
suggest to include some improvements into the GWT compiler.

The article is placed there:
http://techzone.enterra-inc.com/?p=25

We will be glad to listen any critique or ideas about implementation
of HTML patterns inside the GWT core.

Thanks in advance

WBR, Alexey Kharlamov

[Ping]

I'm guessing that you guys work could integrate tightly with the
declarative UI that's announced in the incubator. The article is nice,
the big con of handling browser quirks when specifying html sure is
important, but should be mitigated by the most common cases. I'm also
guessing that the important differences between the most common
browsers are on the css and dom field, not on the html field.

Maybe we should ask about the status of the incubator's declarative
UI :)

[rudolf michael]

Hello,
Intresting article...
We're also moving to GWT and i have been working over it since 3 months now. I totaly agree with you on the HTML segment part, we have already figured out that doing the design using pure html and css is much much faster then using the GWT Panels components. what we are doing right now is retrieving the HTML page using an HTTP Request, then every Class/HTML Page will update its HTML code by creating and setting the widgets. we have used HTMLPanel to load the html pages and then use panel.add(Widget, htmlID) to add the widgets, everytime the page has finished loading its widgets. we're adding it to the RootPanel, our RootPanel consits of one static html page where it contains html ID. the problem is that i still have some performance issues specially if a registration page has like 80 widgets to set where every widget has an http call to get its data from the server. so i will try to use DOM.setInnerHTML instead of RootPanel().get("HTMLID").add(htmlPanel); do you know which one is faster to execute?

[Alexey Kharlamov]

Miguel,

thank you for the hint. Yes, it seems the DeclarativeUI have some
common with our idea.
May be it requires some support of multiple instances, however.

BTW, do you know anything about the declrative UI status? :-)))

[Denis Haskin]

rudolf michael wrote:
> Hello,
> Intresting article...
> We're also moving to GWT and i have been working over it since 3
> months now. I totaly agree with you on the HTML segment part, we have
> already figured out that doing the design using pure html and css is
> much much faster then using the GWT Panels components. what we are
> doing right now is retrieving the HTML page using an HTTP Request,
> then every Class/HTML Page will update its HTML code by creating and
> setting the widgets.

Gee, sounds a lot like Wicket :-)

dwh

[Renat Akhmerov]

Hello everyone!

> the problem is that i still have some performance issues
> specially if a registration page has like 80 widgets to set where every
> widget has an http call to get its data from the server. so i will try to
> use DOM.setInnerHTML instead of RootPanel().get("HTMLID").add(htmlPanel); do
> you know which one is faster to execute?
>

> On 2/13/08, Ping <miguel.p...@gmail.com> wrote:
>

Answering to your final questions I could say that the first way is
faster (using setInnerHtml() method)
because otherwise you in fact would use the standard GWT mechanisms to
attach the large DOM object.
As I understood you, you use RootPanel().get("HTMLID").add(htmlPanel)
to create some sort of layout
or it may be called "working area" or something like that. This
layout object is based on HTMLPanel and
is composed by multiple objects calling panel.add(Widget, htmlID).
Actually, this method as a result does work
via DOM.appendChild() method as well as in case with RootPanel, these
are the same methods of base class
ComplexPanel.
So, inspite of that you are using HTMLPanel class to build your
complex object not using setInnerHTML.
Yes, HTMLPanel allows to build components from html sources but its
implementation always uses
appendChild that is much slower than setInnerHtml.
I don't know whether I delivered the main idea or not :) The key point
of the approach described in the article was
in using setInnerHtml for attaching a frame of some component we want
to show on the screen. At least the frame because
actually we realize that it is not convenient way to always do so
because of lots of reasons, in particular, because this
attached component becomes weakly managed by the program (we attached
a chunck of html-code, that's all) instead of
having a plain java object (if we are saying about Java-development
phase).
One thing we understood using GWT is that there is no such a silver
bullet that would solve performance troubles. You
should analyse your concrete situation to make the best decision.

Well, if you have some questions or comments, please write them here.
We would be extremely pleased to discuss any related
things.

[rudolf michael]

Guess what!!!! i just tried replacing RootPanel.get("id").add with DOM.setInnerHTML("id")

most of my images did not load when i used setInnerHTML() instead of RootPanel().add();

seems that we have another problem in here if we go with the DOM object. Actually i rarely use DOM in all my code.

now we might have another solution for it probably to use an ImageBundle to load the images..

any comments?

 

--
Best Regards,
ruds

[Renat Akhmerov]

Hmmm...
It doesn't look like the problem is in using setInnerHtml(). It's
should the same thing from the end user's point of vew.
What are the images you are talking about? Are they inside the widgets
connected to HTMLPanel or they are a part of
html-pattern that you use with HTMLPanel?

You know, we had pretty lots of troubles with pictures loading in our
project but they appeared only in Internet Explorer.
Each time we had to solve it diffrent ways, for example, changing an
order of initialization for the picture object. Sometimes
a picture stops being loaded after one or more event handlers have
been attached to the object. We were unable to find a
reason of such behaviour, in other words, we were inclined to think of
it as of a bug in IE.

[rudolf michael]

well this might be bc i have used DOM.setInnerHTML("Id", htmlPanel.getElement().toString());

i didnt find an alternative way of getting the html content of a HTMLPanel.

i have done an asbtract class that fetches the HTML string then an abstract method that is overriden by all the classes where every class sets up its own widgets. the class is a composite, it starts by setting the Ids inside the HTMLPanel, once the class is done of setting its own widgets, it adds itself to its parent. now instead of using parent.add("Id", htmlPanel), i used DOM.setInnerHTML("id", htmlPanel.getElement().toString()); when i did that most of my images did not show up, not to mention that the listeners also are not working.

i can show you some piece of code, if you're intrested. but i guess you need to strucutre your code in a different way if you're using DOM. bc when using DOM , you cannot start settings any HTML code before it is being added to the Browser. and you need to sink and unsink events(which i always try to avoid). so i just find it easier to load my module using pure widgets, then use the DOM for validating forms.

i will try to host my product once it is finished over a web site, to let you see a demo.

another issue that it might be intresting to discuss also, is how to retrieve data from the server side. i have been experiencing heavy performance when parsing XMLs, as i am using web service calls to send/receive data from the server. Apparantly RPC is much faster specially with the use of POJO classes, but i havent tested it as i am bounded to use IIS web server and setting RPC over IIS is a pain in the ass to do.

--
Best Regards,
ruds

[Alexey Kharlamov]

The quickest wire format is JSON. GWT uses a kind of optimized JSON to
serialize POJO objects.

So you can try to reengineer your web-services to send JSON objects
instead of XML, which can be quite costly to handle on the client-
side.

[Ed]

Thanks for the articel.

Always nice to get some tips and tricks from people that make
enterprise GWT apps.

BTW: Mygwt creates his widgets the same way as what you call Fast
Container pattern....

[Ed]

Hellu,

- Is it possible to some an example code ?
- Just currious?: do you use (always) tables for your widgets ?... or
div's ... ??.... how do you experience this... and you run in
quirksmode/standard... ?

[Alexey Kharlamov]

Thank you for the kind words.

Your are right, MyGWT uses similar methods to accelerate rendering,
but not exactly.
But I suspect the library provides less optimized but more general
implementation.

Do you have any stats about its performance. i.e. how many components
does it
capable to produce per second on a mid-level computer?

[Alexey Kharlamov]

On Feb 15, 1:25 am, Ed <post2edb...@hotmail.com> wrote:
> Hellu,
>
> - Is it possible to some an example code ?

Yes, we are working on the IP aspects at the moment.

> - Just currious?: do you use (always) tables for your widgets ?... or
> div's ... ??.... how do you experience this... and you run in
> quirksmode/standard... ?

We run in standard mode and use tables to render our widgets. It is a
pretty strait-forward way and it fits very well for our requirements.
The most challenging tasks were linked with the differences in
dynamic behavior models of browsers (focus management for example).

[Renat Akhmerov]

Not a problem,

Please deploy your application and give a link, also you could provide
a piece of code so we can review what the problems there can be.

[Renat Akhmerov]

As for using setInnerHtml method of DOM we don't recommend to use it
always. In the article we just tried to show that it gives some
perfomance (significant) benefits and a little bit more comfortable
way to develop components via plain HTML coding. Mentioning our web
application for tasks management we didn't see some other alternatives
to reach the appropriate results, that's all. But we recognize this
approach have many disadvantages. Say it makes us solve cross-browser
problems by hands and many more. So using this you should be careful
as much as possible because of those problems, besides that you should
be absolutely sure you aren't able to reach desired results with
standard GWT technics.
This would be our advice :)

On 14 фев, 15:48, "rudolf michael" <roud...@gmail.com> wrote:

[Ed]

He Alexey,

Thanks for your answer.

I have no idea what the benchmarks are of mygwt.
Have a look at this topic: http://mygwt.net/forum/viewtopic.php?t=803&highlight=.
Look at the code example half way... (I was just discussing this topic
with Darrell as we speak).... ;)
As fare as I remember, it uses mostly setInnerHtml()..

- Why do you used doctype standard mode ?.. and not the
quirksmode ?... I remember reading in this forum that standard mode is
poorly supported...

> The most challenging tasks were linked with the differences in
> dynamic behavior models of browsers (focus management for example).

- Interesting... can you give some insight in the problems you
encountered ?

- I am looking forward to see some example code. Please let me know
when it's there ;)

[Renat Akhmerov]

Hi Ed!

> - Why do you used doctype standard mode ?.. and not the
> quirksmode ?... I remember reading in this forum that standard mode is
> poorly supported...

I don't exactly understand what did you mean under "poorly supported".
What does work badly in the standard mode?
How does it influence on the perfomance? Could you explain this point
a bit more detailed?

> - Interesting... can you give some insight in the problems you
> encountered ?

Well, there were plenty of rendering issues related with differencies
between browsers behaviour. One of the problem was in pictures loading
in IE. We periodically were not able to make IE load pictures in some
conditions! We still are not aware of causes of this problem and had
to solve it some different way each time it appeared. It looked like
some IE bugs and nothing more. Also there were many problems related
with rendering itself in IE, Firefox and Safari. It was pretty
difficult to create some component looking the same way in all of
those browsers. Sometimes this was related with different default
style values or say different alignment mechanisms in IE against other
ones. You probably know that IE implements different box model from
HTML/CSS standard, so we had to deal with it as well. So there we many
problems, some of them appeared because of using setInnerHtml() and
respectively we had to complete cross-browser HTML-code for such
components.

Besides that, we had serious problems with focus management for the
components in our system. If you look at the article one more time you
will be able to see Figure 2 which shows one of our components. Every
separate control included into the component is a so-called In place
editor. So when you click on it you will get a text box to edit the
value of the control. It's not very hard to implement itself but the
most intresting things start when you press Tab button or Shift+Tab!
Of course, you understand that standard focus management mechanism
will fail in this situation. A browser will switch a focus to some
other focusable control by its own opinion. But a normal flow would be
if a focus moved to next control in this component that is also In
place editor but yet in the show mode.

So to get comfortable mechanism to manage the focus we implemented our
own mechanism for focus management which allows to deal with either
standard focusable elements (text boxes, combos etc.) or some complex
components such as In place editors or even more sophisticated ones.
This thing also encapsulates the differencies of browsers behaviour
inside so that a client should not be able of them.
Having this tool we didn't already have any problems to ingegrate any
even very complex components to focus management sequences.

Actually, we were going to write a separate article about this focus
management mechanism because I think It is pretty interesting
thing :))

Well, excuse me for such verbose answer. I hope I was able to provide
you some information you were interested in.

[Ed]

Thanks Renat,

I looking forward reading some more about your focus management tool
in the upcomming article you talked about.

Anyway about your doctype question: just search in the forum on
"doctype" and you will find plenty of info about it. FOr example:
http://groups.google.com/group/Google-Web-Toolkit/browse_thread/thread/cd42ce23cd2c55b0

And have a look in the issue tracker, search for doctype. There are a
few issues with standard mode, that should be resolved in 1.5

Also:
- http://mygwt.net/forum/viewtopic.php?t=641&highlight=doctype

I hope this helps....

[Renat Akhmerov]

Ok, Ed

Thank you for the links!

It looks like I should really dig into this question. To be honest, we
didn't seriously think about this. I mean which of standard or quirks
mode to use.

On 15 фев, 15:29, Ed <post2edb...@hotmail.com> wrote:
> Thanks Renat,
>
> I looking forward reading some more about your focus management tool
> in the upcomming article you talked about.
>
> Anyway about your doctype question: just search in the forum on

> "doctype" and you will find plenty of info about it. FOr example:http://groups.google.com/group/Google-Web-Toolkit/browse_thread/threa...

>
> And have a look in the issue tracker, search for doctype. There are a
> few issues with standard mode, that should be resolved in 1.5
>
> Also:

> -http://mygwt.net/forum/viewtopic.php?t=641&highlight=doctype
>
> I hope this helps....

[Sumit Chandel]

Hi Alexey,

This is indeed an interesting article. Thanks for sharing!

The GWT team has actually be looking to further optimize UI libraries, pending the GWT 1.5 release. Something similar to this idea has already been suggested, but the exact design and implementation details of how we can provide the same easy-to-use API while speeding up widget load time is still on the cutting floor. I think the idea you suggested here could have a lot to do with finding a good solution to that end.

An example of something that falls along the same lines are the BulkTableRenderers (currently in the GWT incubator). The basic premise is the same, however it is only applied to a couple widgets rather than the whole set. You can check this out at the link below:

BulkTableRenderers:
http://code.google.com/p/google-web-toolkit-incubator/wiki/BulkTableRenderers

Could you start a thread about this on the GWT Contributors forum, with a link and brief abstract about the article there? You're likely to get a lot more traction from other GWT contributors as well as input from the GWT team, and we can further explore how to make the UI library even faster.

GWT Contributors:
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Thanks,
-Sumit Chandel

2008/2/15 Renat Akhmerov <renat.a...@gmail.com>:

[davidroe]

I have tried to follow the approach described in the article "GWT:
improving performance" - http://techzone.enterra-inc.com/?p=25

I have classes that render different HTML "templates" and various
controls that are placed into the skeleton, much like the
FastContainer pattern described in the article.

My HTML appears intact and the controls appear as expected, but I am
unable to receive any events fired by listeners attached to these
controls.

Has anyone who has implemented the FastContainer pattern seen anything
similar to this?

I have attached a test-case that, albeit a simple version, highlights
the exact problem.

/dave

--------------------------------- 8< ---------------------------------
package com.rt.client;

import java.util.HashMap;

import com.google.gwt.user.client.DOM;
import com.google.gwt.user.client.Element;
import com.google.gwt.core.client.EntryPoint;
import com.google.gwt.user.client.ui.Button;
import com.google.gwt.user.client.ui.ClickListener;
import com.google.gwt.user.client.ui.FlowPanel;
import com.google.gwt.user.client.ui.FocusListener;
import com.google.gwt.user.client.ui.Label;
import com.google.gwt.user.client.ui.RootPanel;
import com.google.gwt.user.client.ui.TextBox;
import com.google.gwt.user.client.ui.Widget;

/**
* Entry point classes define <code>onModuleLoad()</code>.
*/
public class RTTest implements EntryPoint {

/**
* This is the entry point method.
*/
public void onModuleLoad() {

final Button button = new Button("Click me");
final Label label = new Label();
final TextBox textbox = new TextBox();

FlowPanel flowPanel = new FlowPanel();
if (false) {

// Change this to "true" if you want to see how straight-forward
widgets behave

flowPanel.add(button);
flowPanel.add(textbox);

}
else {

// Create a chunk of HTML and use it as the "template" for a
FlowPanel using DOM.setInnerHTML
// Create two placeholders where the controls will eventually be
inserted

String buttonID = "button";
String textboxID = "textbox";

String panelHTML = "<div id=\"" + buttonID + "\"></div><div id=\""
+ textboxID + "\"></div>";
DOM.setInnerHTML(flowPanel.getElement(),panelHTML);

// The elements are not in the DOM yet, so DOM.getElementById()
does not find them
// Instead, find all elements with an attribute id= in the newly-
created HTML

HashMap namedElements = new HashMap();
findNamedElements(flowPanel.getElement(),namedElements);

// Grab the DOM element we just found and append the control to it

Element buttonElement = (Element) namedElements.get(buttonID);
DOM.appendChild(buttonElement,button.getElement());

Element textboxElement = (Element) namedElements.get(textboxID);
DOM.appendChild(textboxElement,textbox.getElement());

}

RootPanel.get("slot1").add(flowPanel);
RootPanel.get("slot2").add(label);

// Regardless of where the listeners are added (before or after
they are added to the RootPanel)
// they do not appear to register as they do not fire when the
control is clicked on

button.addClickListener(new ClickListener() {
public void onClick(Widget sender) {
if (label.getText().equals(""))
label.setText("Hello World!");
else
label.setText("");
}
});

textbox.addFocusListener(new FocusListener() {
public void onFocus(Widget sender) {
textbox.setText("focus");
}
public void onLostFocus(Widget sender) {
textbox.setText("lost focus");
}
});

}

// given a starting point, recursively search for elements that have
an id= attribute

protected void findNamedElements(Element element, HashMap hashMap) {

String id = DOM.getElementAttribute(element, "id");
if (id != null) {
hashMap.put(id, element);
}

Element firstChild = DOM.getFirstChild(element);
while (firstChild != null) {

findNamedElements(firstChild,hashMap);
firstChild = DOM.getNextSibling(firstChild);

}

}
}

[davidroe]

the solution appears to always add the controls to the parent (the
flowPanel). the call to DOM.setInnerHTML appears to leave the children
intact, so when the parent is attached, it attachs the children into
the GWT event system. From what I can tell, the children are also
correctly detached.

/dave

On Feb 22, 4:28 pm, davidroe <roe.da...@gmail.com> wrote:
> I have tried to follow the approach described in the article "GWT:

> improving performance" -http://techzone.enterra-inc.com/?p=25

[Renat Akhmerov]

Hi, davideroe

I've just seen your code snippet. I find a pretty strange way to
access DOM.elements using your findNamedElements() method. You wrote
that "// The elements are not in the DOM yet, so DOM.getElementById()
does not find them". But if I understood, you need to access div-
elements with respective id-attributes and they should already be in
DOM after DOM.setInnerHTML(flowPanel.getElement(),panelHTML);
following your code.
As for event handlers, have you tried to set up event handlers before
attaching your controls (button and textbox) to DOM?
Yes, there are some weird things happening with event handling but in
your example it looks correct, at least at the first glance.

On 23 фев, 06:28, davidroe <roe.da...@gmail.com> wrote:
> I have tried to follow the approach described in the article "GWT:

> improving performance" -http://techzone.enterra-inc.com/?p=25

[davidroe]

I would have expected to find my div elements that have an id, but
DOM.getElementById() found nothing. even though I have called
DOM.setInnerHTML(), that particular element is not yet attached, hence
the need for another way of finding the elements.

With regards to the events, everything works as expected as long as
you first add() the controls, so that GWT becomes aware of them.

/dave

[Renat Akhmerov]

Hi, davidroe

Yes, you are right about DOM.getElementById(). Really, there is a
strange behaviour in this case seemingly caused by setInnerHtml()
call. I reviewed our real working code of our last project and found
that we used a little trick to deal with this situation. I've created
a little example of that demonstrate the approach described in the
article (now I'm writing the description of the example), we are going
to share the example and its description in the near future. So, here
is the essential code where the trick I've just talked about is:

public class FastContainer extends Widget {

private Context context;

public FastContainer(Pattern pattern) {
this.context = new Context();

Element creatorElement = DOM.createDiv();
DOM.appendChild(RootPanel.getBodyElement(), creatorElement);

DOM.setInnerHTML(creatorElement, pattern.generatePattern(context));

Element elem = DOM.getFirstChild(creatorElement);
setElement(elem);
}
....

Please take a look at this code carefully. This works! Unfortunately,
I don't even know why the straightforward (setting inner html directly
into getElement()) way doesn't work.

[Renat Akhmerov]

davidroe, hi again!

I'd like to show a little snippet that explains how you should solve
your problem with event handlers:

public class FastContainer extends Widget {

...
public void setWidget(String fieldName, Widget widget) {
Parameter param = context.getParameter(fieldName);
if (param == null) {
throw new RuntimeException("There is no such parameter in
context!");
}
Element element = DOM.getElementById(param.getId());
if (element != null) {
widget.removeFromParent();
DOM.appendChild(element, widget.getElement());
DOM.setEventListener(widget.getElement(), widget);
}
}
...
}

Just pay your attention to the last row:
DOM.setEventListener(widget.getElement(), widget);

This action repairs event handlers that have been associated with
attached widget. This is what actually all panels do when attaching
their children.

[walden]

Don't you just need to put the 'find' part into a DeferredCommand? I
don't understand why inner HTML not yet attached to the document is
findable by findNamedElements() unless somehow that call is getting
delayed until after attachment.

> > > }- Hide quoted text -
>
> - Show quoted text -

[davidroe]

I think that the DOM fails to find the child elements by ID because,
even though the call to DOM.setInnerHTML(parentElement,htmlString) has
happened, the fact is that the parent element has still not been added
to the actual DOM.

/dave