вторник, 24 января 2012 г.

GWT widget performance and optimization solution

Many times we have heard stories about how slow GWT widgets are. This is my story about that. I work in big company, owner of one of the biggest social network portals in the world. We have more than 100 million users. I’m GWT developer, and I’m responsible for web performance and music service on this portal.


It all started when we have developed our first music service prototype. We had to show users big lists of tracks. Each track was a GWT widget. And each track had 6-7 active elements, and each of them also was a widget.







During prototype testing, I have noticed that big track list rendering takes a lot of time on old browsers. So I started to dig into the problem. First of all, I’ve created a test case, which contained 163 tracks, and made measurements, results was lamentable: IE6 took 4.5 sec to render this list, FF4 took 0.5 sec.



First improvement I’ve made was removing of all event listeners from widgets and made one in tracks container. Each active element got unique “id” attribute to make it possible for event listener to identify which element was clicked. Each track container got “data-query” attribute with JSON data for event listener to make necessary action after click. In this case this is track id, which needed to find track data in music model.





For example, in music play history we need not only track id, but also track position to identify track on the screen for highlighting, because we can have more than one track with the same id there.





Taking in account fact that all widgets where using UiBinder, I was hoping for good results. But in reality results were as following: IE6 – 4 sec, FF4– 0.35 sec.
My next step was to delete all widgets and build HTML using the simple string concatenation. Events handling wasn’t a problem at that moment, because of my pervious improvement. But result was superb: IE6 – 0.85 sec, FF4 – 0.15 sec.





Such performance was good enough for me, so I stopped future investigations. But this solution was tested in several others projects on our portal, such as messaging and discussions and every time we made services 3-4 times faster.

1 комментарий:

  1. Where interaction is minimal or non-existant, strongly consider using Cells to render large data sets - while somewhat harder to work with (just strings, no element interaction when building content), they are quite efficient, as the cell widgets produce the entire content as an html string before attaching it to the dom.

    Also worth pointing out: UiBinder xml compiles to nearly the same Java that you yourself would write, so there should be no expected improvement there. The only difference would be where you use different widgets, like Html or HtmlPanel in place of composed elements.

    ОтветитьУдалить