Poor table performance when used with large data set

The Table component becomes unresponsive when i use it with a dataset having 250 columns and 200 records in it.

My application isnt a production app but a kind of testing app which i use to test various advanced ui frameworks. Is there any benchmark made for the Table component.

I am using one of the GWT frameworks for the same app for internal use and the performance of that app is much better compared to vaadin.

My comp spec:
2.5gb RAM
Windows Vista
Google Chrome 3.0.195.x

Do you use any generated (e.g. no standard columns or columns with controls) or just plain text columns the table provides by default ?

Try tweak the table rendering engine to reduce the number of invisible table areas that are rendered above and below visibla area in advance, to smooth up the scrolling - this can give negative drawback on heavy table:

table.setPageLength ( 10 );
table.setCacheRate ( 0.1 );

I did not ever try 250 column table, but our production applications runs tables with 10 columns and thousands of rows quite acceptable on dummy IE6 and nicely running on FF3 and Safari

Hi guys,

I can surely believe that the Vaadin Table gets pretty slow if you have 250 columns in it. I do not, however, see any real-world application for having so many columns in a table. In a real application you probably want to have less than a tenth of that due to the complexity that too many columns would bring to your application. Users don’t like scrolling horizontally :wink:

The slowness probably comes from the calculation of column widths and other layouting in the Table.


Note to the author: this section of the forum is reserved for
Vaadin Testbench
related discussion.

Our admins could move this thread to a more appropriate section.

Then about the problem: having 250 columns in a table is sure to cause performance issues. The Table component’s client-side counterpart (widget) was not designed to handle that amount of columns efficiently. With a quick calculation, I’m estimating a 250202 = 10000 DOM elements being generated for 20 rows of data. The amount could easily be much larger, but I can’t say about your situation.

One other thing that will definitely affect the performance are additional components inside the Table. Plain text content is much faster to render than say a TextField (let alone layouts).

What’s the other framework you were testing?

Moved this thread to Miscellaneous Discussion category.


Lots of answers already, but quick summary about Tables performance here:

  • As stated by Dmitry, because of lazy loading it scales exceptionally well for rows and does it with rather good usability. Try 50 000 rows with other gwt data tables.
  • for columns it does not scale in similar manner (no lazy loading, like for rows)
  • maximum number of columns visible with acceptable performance varies on
    • how many columns are collapse/visible at the same time (see setColumnCollapsed)
    • number of rows visible
    • cache rate
    • type of cell content (complex components vs. plain text)
    • browser used (webkits can be more than ten times faster than FF for some content and we yet have IE)

There have been some requests to implement horizontal lazy loading too, but there would be quite many problems to solve (like how to estimate the size of columns not rendered).

If you really really need that many columns visible at the same time, I’m sure that with a simpler data grid implementation Vaadin could easily come up with similar performance characteristics as other GWT implementations have. You could also try wrapping your favorite GWT data table in a Vaadin widget. See Book of Vaadin for more information.


Just a quick idea that occurred to me, shoot it down if it’s a bad one.

How about if the table would always show whole columns, and one could set the amount of columns shown? The horizontal scrollbar would reflect the ratio of columns shown/hidden instead of the pixel width ratios.

This approach results in a somewhat “choppy” horizontal scrolling experience as whole columns disappear to the left and new ones appear from the right, and the table resizes the visible columns every time. Would it be a problem?

+1 for this approach,

We have developped an application following the design of a good old application written in C++
Our customers don’t want to be lost using a new application.
That’s why when migrating from the previsous application we have to implement a big table with lots of columns (20-30 columns)
But the more columns this table contain, slower the application become. especially if there are some css generated lines (like coloring a whole line with the state of a value in a column)
It seems like designing the table and adding lots of column slow down dramatically the scrolling.
Do you think such an implementation will be taken into considerations ?

I would be doubtful about this making it to the core - I would still qualify it as a marginal feature (needed by few), and it would add quite a bit of complexity to the table component, which is complex enough as it is (the client side is over 5000 lines of code, and the server side over 4000). Other improvements probably have a higher priority.

I believe the problem is primarily one of rendering (loading the extra columns from the data source and sending them to the UI are not bottlenecks in most cases), so this could be addressed purely on the client side by tweaking the visible columns list based on some scrolling control - or even on the server side if the horizontal scroll speed is not an issue. Feel free to make an add-on out of this.

I am working with Vaadin 7 and i have problems with performance and Vaadin Tables too.

I developed an application based on quicktickets dashboard that build reports… I have a report with at least nine or ten tables with 60 columns and 10 rows… server process time is good but client side render time is a disaster.
Maybe Table component has some configuration to make it fixed size, without scroll and faster… i don’t know… i still not probe it

Vaadin is a framework with some good ideas, good look, but bad programing code style, and really bad performance. It’s ideal only for really small applications with low traffic or little autogenerated code applications.
I worked with GWT and i know about its limits… but i thougt that Vaadin could be a better experience. In my opinion Vaadin at least needs to improve: code organization, patterns, good practices, performance (widgets optimization).
Positive points: documentation, some examples, sample look and feel, auto generation code posibilities easily, ui component model, plugin market.


I forgot to mention that i need to show tables on screen because i need to show a report preview before convert it to pdf and to give to user a chance to modify it.


The current Table component is quite the code mess as a result of it being around since Vaadin was still called It Mill Toolkit.
As a result its implementation is not that great when it comes to performance or extensability. When there are a lot of columns maybe even with components inside them the performace seems to suffer the most.
Fortunately the Vaadin team is currently working on a new Table component called Grid which will be in Vaadin 7.4. (There is a first “in development” version in some alpha or beta but i don’t remember which one).


Vaadin Table component is by no means designed to display lots of data in reports. It is more a UI component to e.g. scroll through lots of data, with sane number of columns visible, and then select a row or rows for editing. I bet your UI could also be designed so that only some of the data, and relevant columns, is displayed at once. Then add UI controls that configure what is shown on the screen. I don’t know anything about your exact use case, but showing 6000(106010) cells on a screen don’t sound very UX friendly to me.

If you just want to display lots of data in multiple tables in a static report in a browser, you are most likely better of by rendering that into e.g. HTML table and display it directly as HTML. I have some times used e.g.
templates together with HTML Label components.


For me, Grid is lot more sluggish in Vaadin 7.7.9 than Table. And Table is lot more slaggish in Vaadin 7.7.9 than in 6.8 :frowning: