got a serious performance degradation yesterday - I have a multi-view - style application, where one active component (view) is visible at one time from a set of available views.
In one view there is a Table, in another view - a form. When user clicks an item in the table, clicked row data is loaded into the form and it becomes active. When "< Back" button pressed in the form, view is switched back to the table.
The problem is when Table contains, for instance, 70 rows - when switching back from form to table view, it takes very long time - 3-4 seconds with Safari and about 8 seconds on IE.
The data container in a table is in memory one, so there are no slow DB queries or so, in case table wants to reload all the items. However, slowdown occurs. If there is 1…5 items in the table, the view switch is instant. So it looks like the number items in a table does matter.
Im switching the views by removing one and adding new components to the master view container (VerticalLayout). Does this makes sence ? Maybe it is better to use setVisible properties instead of add/remove methods ?
You may check this also live in the following sample:
One tip to try: use undefined width for Labels inside your table. We recently set Label to be 100% width by default.
Another tip is to use plain text content (instead of Label component) in table whenever possible. Label has quite a lot of features (yes, in Toolkit it really does ) and it is not that fast to render as a plain text content.
Hm, is Label used in a table by default ? Im not using labels explicitly. The only custom column generator in this table is for the last column , where it displays a HL with 3 buttons, all other columns are generated by default
Upd, sorry, I previously said that I do not have Labels in a table - but I do have them, in 3 dummy columns (they’re added temporary, while datasource is not configured properly).
Hiding those columns speeds up the process. But if I also remove the generated column with 3 buttons - the switch is almost immediate.
However, when I just set the datasource to that table, the delay (with all columns visible) is not such long as when I hide/show it.
When switching back to visible the table does row rendering bit differently. On first load it first renders one “page” (see setPageLength). After the initial rendering it makes a server visit on background and loads some extra rows to make scrolling bit smoother. On second load the table remembers how many rows it had (including cache rows) and more rows gets rendered at once. That is why it may feel bit snappier on first load. Tuning pageLength field might help a bit if you have a custom size for your table.
The table component has a long history and needs some refactoring soon, but I can’t promise when we have time to do it. It will be quite a large task.
If the column with HorizontalLayout and buttons is the one that slows things down the most, I’d guess it is the layout we’d need to optimize here. Layouts got quite a lot of slower in some configurations since 5.3, but they render correctly in pretty much every configurations. Especially relative sizes in complex component like Table may slow down things quite a bit.
If you don’t need all the fancy features in your layout, you might want to try an incubator project of mine:
Those are already used in one project to build huge reports. Rendering time was pretty much unacceptable with default layouts, but with FastGrid it became pretty snappy. FlowLayout is even faster. Some features are lost (compared to GridLayout/HorizontalLayout/VerticalLayout/) and you may have to use CSS to tune the UI, but most often one can workaround the limitations.
) and it is not that fast to render as a plain text content.