6

I've read an answer 2 years ago about UiBinder performance https://stackoverflow.com/a/3755675/1067931 And decided to put it to a test.

I built a really complicated layout with many buttons, and panels one inside another. version 1 had the layout built purely in UiBinder xml, while version 2 purely programatically.

I deployed both versions to App Engine and ran both versions, while clearing browser cache before each run. Version 1 (UiBinder) loaded after ~12 seconds, while Version 2 after ~3 seconds, so it really discouraged me from using UiBinder. Did you have different impressions?

Community
  • 1
  • 1
user1067931
  • 63
  • 3
  • 1
    When measuring something, always define clearly what exactly you are measuring. *How is UI rendering speed related to the browser cache or where you deployed the app?* If it depends on these factors, then the performance bottleneck is probably not UI rendering or DOM manipulation (e.g. maybe in the UiBinder variant you're using a different method to load images?) – Chris Lercher Oct 17 '12 at 11:00

2 Answers2

2

UiBinder, just like any GWT generator, generates Java code. So first, go read what's generated and compare that to what you'd be writing by hand (pass the -gen option to the GWT Compiler or DevMode to make it write the generated code down to disk).

Where UiBinder shines is with HTMLPanel and I18N, because it makes the code so much more readable than when written in Java.

GWT 2.5 also introduces IsRenderable and RenderablePanel as an experimental feature that however can boost your perfs under some conditions (they made it for boosting perfs of Orkut). Again, UiBinder makes it easy to use (IsRenderable otherwise requires calling its methods in the appropriate order, and at the appropriate time to get maximum performances; UiBinder makes this transparent). There unfortunately are no other IsRenderable widgets than RenderablePanel, so it only helps if you create your own widgets that implement IsRenderable; and IsRenderable operates at a very low level.

Generally speaking, UiBinder shouldn't perform slower than hand-written code (for the equivalent arrangement of widgets of course). When people say UiBinder performs better (outside IsRenderable) is that it encourages you to use HTMLPanel rather than panels for layout. For instance, an HTMLPanel containing an HTML <table> or a set <div>s performs way faster than a FlexTable or a bunch of FlowPanels (assuming you won't need to modify the layout dynamically).

Thomas Broyer
  • 64,353
  • 7
  • 91
  • 164
1

It seems intuitively right to me, that UiBinder-Code can lead to longer start-up times. here is why:

Imagine you are trying to define 20 Buttons in your view. In your declarative layout you would declare each button explicitly, while in your imperative layout you would most likely use a for-loop. It seems likely that this would lead to smaller JS size for the imperative layout.

Also consider that in real world applications, this difference might be negligible, as views usually are the smallest part of a project.

The documentation of UiBinder seems to suggest, that it is more about runtime performance, so if you are interested in decreasing load time I suggest you take a look at
Code Splitting,
HTML5 Appcache
and general performance tips (though a bit outdated, still very useful!)

Thanks for the question, I searched for an extensive performance test suite for GWT features ( like UiBinder ) but came up empty.

Community
  • 1
  • 1
Oliver Jan Krylow
  • 1,758
  • 15
  • 22
  • You were right. When I weren't using a for-loop to build the imperative layout it loaded slowly. The UiBinder and Imperative loaded exactly at the same time. – user1067931 Oct 17 '12 at 16:39
  • Wow, I feel so vindicated in avoiding UI Binder. Coding in XML annoyed me so much I wrote a bean builder generation utility: http://b-generation.freshcode.biz. So now I use giant method chains that resemble html anyway. – Peter L Aug 19 '15 at 23:59