Last week we upgraded an application for one of our customers from ITMill 5 to Vaadin 6 and noticed a huge performance degradation (even with Safari on Mac. IE and FF3 were totally unusable, showing constant sandglasses and yelling “javascript execution takes too long, abort?”) with search results listing, where we use table with a generated column.
Generated column contains 3 buttons to perform quick actions in pace, while browsing the table data. There we no such performance slowdown with ITMill 5. (Table does contain about 1000-5000 entries, with a page size from 5 to 50 elements, backed by pre-loaded container on the server side - so there were no database/query delays.)
The generated column was made with a HorizontalLayout with 3 Buttons on it. For every row, a new instance of such compound component is created. When this generated column is toggled off, tables performance returns to its normal state - amazingly fast
We currently solved the problem by creating 3 generated columns instead of one, adding a Button object instance to each column, thus, eliminating use of HorizontalLayout. In this case, performance is almost normal, a bit slower than without generated columns but only a bit and well acceptable for production.
My questions is if there are any other considerations or tips for raising up UI performance when a non-standard data had to be displayed in a table ?
According to your comments it seems to be the layout that causes the problem. That should only be a few div’s so it sounds wierd. Have you tried having a generated column with only a HorizontaLayout in it, without any content. Does it still perform as bad?
The unofficial quick fix for this kind of performance issues is to use FlowLayout or FastGrid from http://dev.vaadin.com/browser/incubator/FastLayouts . Note that the current widget set there in the jar file is not in sync with the latest release, so I suggest that you compile it yourself.
They (layouts in fastlayouts project) lack some of the layout features, but one may usually overcome the limitations with CSS. Also using relative sizes inside “fast layouts” may/will fail. But they really render fast.
Layout performance has truly gotten worse during last 12 moths in some areas, but on the other hand the standard layouts are very flexible atm and even work in IE6. We will try to resolve some of our client side performance issues during next couple of weeks, but I wouldn’t promise a return the the original 5.0 level yet.
to my feelings, performance with layouts is mostly noticeable in tables, in situations from above. In other cases like building complex UI screens, it is not noticeable at all on a Mac(Safari) and visible but not so deadly in IE6 on Windows.
And yes, will also add my 2 cents - current layouts works really great and easy and which is most important - equally in all browsers ! Thanks again to all of your hard work on this, guys !
[quote=Dmitri L Livotov]
Last week we upgraded an application for one of our customers from ITMill 5 to Vaadin 6 and noticed a huge performance degradation (even with Safari on Mac. IE and FF3 were totally unusable, showing constant sandglasses and yelling “javascript execution takes too long, abort?”) with search results listing, where we use table with a generated column.
[/quote].
The reason for this performance drop is the inclusion of automatic pageLength calculation for the Table (
#1623 ). PageLength has mainly been used as a workaround when a Table was caching rows too aggressively, causing long render times on the client side. As you no longer should (or even can) use the pageLength for controlling the cacche, we have added a new feature Table.setCacheRate(double) (
#3209 ), which enables you to change the number of rows cached by the client side table. This is measured as number of pages below and above the currently visible page, i.e. 2.0 is the old behavior, 1.0 means 1 page above and below, 0.1 means very few rows above and below. Setting the cache rate lower will improve the performance drastically as the client no longer renders as many rows. The additional benefit of this is that pageLength is the same as the actual number of rows displayed and you will not have e.g. 10 row rendered at first and then some more added later on.
Using your test case with the latest development version the rendering time when scrolling randomly in the table dropped from
2300ms (6.0.1) to 400ms (with cache rate 0.1). The user experience is not really affected.
[quote=Dmitri L Livotov]
The generated column was made with a HorizontalLayout with 3 Buttons on it. For every row, a new instance of such compound component is created. When this generated column is toggled off, tables performance returns to its normal state - amazingly fast
[/quote].
The HorizontalLayout is designed as an application layout and is a bit slow for this case due to its rich feature set. We will address this in the upcoming 6.1.0 release by adding a new, faster layout suitable for Tables and other places where you have many components. This layout is based on the FlowLayout from the “fast layouts” incubator project Matti mentioned.
An additional fast (and dirty) layout that will probably solve many performance issues will be included in upcoming 6.1. See:
http://dev.vaadin.com/ticket/3235 .
Another recipe for curing slow tables with lots of UI components: try to use
PopupView where possible. They are designed to be as lightweight as possible: only short snippet of HTML is generated (on demand) when rendering PopupView. You can as many components to the PopupView without any performance impact as they are lazily created only when a user clicks to open the popup.
