Bad UI performance

Hi guys,

I’m in big trouble right now because my application’s rendering performance is really really bad. I’m trying to display about 200 table components (each containing 0 - ~20 entries) that are aligned vertically and horizontally using Vertical/HorizontalLayout, combined with four labels per table and two PopupViews each. All together Vaadin creates about 40 layers of div elements until it shows the actual row text. To display the page initially it takes about 30 seconds, after that, working with the components is more or less smooth.

I tried switching to PMTable (addon) and immediately my rendering time dropped to about 15 seconds, so that was a big win, however, now I’m a little bit helpless on how to further improve performance.

I already found the Wiki page
https://vaadin.com/wiki/-/wiki/Main/Optimizing+Sluggish+UI
, yet it’s not as helpful as it seems. For example, I used to pack all my Components in CustomComponents which supposedly isn’t very good for the performance, so I tried to use CssLayouts (convertig the 400 CustomComponents I’ve got in CssLayouts), yet the performance gain was not even noticeable (less than one second).

Saving the page locally as html file and opening it with chrome is very fast (about 2-3 seconds), so the “deep” structure alone can’t be the reason why it takes that long to open the page…

My main questions:

  • Is there any way to pinpoint what’s the biggest performance killer?
  • Are there any general ways of profiling the application (client side mostly) apart from looking at the debug console and comparing start / end time of different actions?
  • Do you think it would help to convert the layout to GridLayout? I read some places, that GridLayout is not that fast either?
  • Is it important to use pixel width or is size full etc ok too?
  • Any other ways to improve performance?

Thank you very much for your help!

Ok I managed to further reduce the time to load the page:

  • Using Grids instead of the Vertical/Horizontal Layouts: ~2 seconds
  • Using mostly fixed sizes: ~0 seconds
  • Removing Panel that originally wrapped every table to provide click / keyboard listeners, eventually will have to do this differently: 10 seconds (!!)
  • Change some more CustomComponents to CssLayouts / VerticalLayouts: ~1 second

I have now studied the client side debug logs a little bit and noticed that line: "Passing UIDL to Vaadin 6 style connectors ". This single entry needs 10 seconds until the next one follows. I’m I right and this is the main “layouting phase”? Any way to further analyze that part?

Also I expected fixed sizes to make a huge difference, however I didn’t really notice any change at all. Is this a misunderstanding on my side, or do I have to do this the exactly right way in order to have any impact? I actually have no problem using mostly fixed sizes, because all of my tables are the same size anyway.

I’m still very happy to get some feedback on this.

Late reply but might help explain some things.

The Table component is not really optimal in terms of performance - it does perform lazy loading of data etc. but having a lot of tables on the page (especially if those tables contain Vaadin components) can be heavy.

Fixed sizes help the performance of layouts, but not necessarily what is going on inside the Table component. Do you also use fixed column widths? Those might even have more of an impact than fixed component sizes in your case, or a combination of the two might help a bit.

The phase “Passing UIDL to Vaadin 6 style connectors” is primarily not layout but parsing of the legacy style UIDL messages from the server to the client and updating the components accordingly, although it might trigger reflows when things need to be measured in the DOM. The Table component is still using Vaadin 6 style legacy communication for a lot of the server-client communication. The phase is relatively opaque and hard to profile without activating client side profiling and even then the effect of reflows might make it hard to see what really takes time (they might show up in one place, but if eliminated there, they show up elsewhere). However, with this many tables, it might be that just parsing the messages is a significant fraction of that phase.

The upcoming Grid component (for Vaadin 7.4) does use the new communication mechanisms.