Internet Explorer performance and lockups

[ron.lawrence]

We are using smartclient 2.3 nightly pro version, and GWT version 2.0.1.

We are (and have been) experiencing quite drastic performance and lockup problems when running our application in Internet explorer, while firefox and chrome perform just fine. Our application has a tabbed view with several sub-views on each tab, each containing a gridview and other widgets. We often return hundreds (sometimes thousands) of rows from custom datasource(s) on the server to some of the grids (ala http://www.smartclient.com/smartgwtee/showcase/#simple_custom_ds).

As I said above, in firefox this works just fine, and although it gets slower with many rows, it does not lock up or behave badly like IE does. We have tried IE 6, 7 and 8 with no appreciable difference in performance or behavior. We often have the grid freeze for long periods of time, and have had IE completely lock up at times, even when there is no (or very little) data in the grids. We do not have any IE javascript debugging turned on.

I am trying to create a test case that I can post to show these issues (our app is proprietary, so this will take me some time for me to build). I will post this when I've produced it, but in the meantime, do you have any suggestions as to what we might do to diagnose and solve this problem?

[Isomorphic]

IE6 has much lower tolerance for data volume than other browsers, however if you are seeing uniform performance across IE6, 7 and 8, this suggests the problem is not relatee to data volume - especially if there are long pauses.

Look instead for code you might have written that traverses the entire dataset of a grid, and may fire when the dataset is still being fetched (ResultSet.lengthIsKnown()). If you do this, you end up traversing 1000 slots because getLength() simply returns a large number while data is still being loaded. This is a good candidate for freezes.

[ron.lawrence]

Thanks for the suggestion. I don't think we have any code that is doing this, but I will look for this to be sure.

I'm having slow progress reproducing this in a standalone project. I have produced a similar grid that does not exhibit the behavior, but does have uniform slow performance across browsers when the number of rows returned is large (over 500 or so). This is somewhat expected, and is not causing IE to freeze, just to load rows slowly. I suspect I will have to replicate more of the complexity of our real project before I see similar behavior. We load a number of xml datasources (30 or at this point) using the DataSourceLoader servlet. Each of these has either a grid or a form in the system somewhere. One of the grids is also fetching rows on a timer every 30 seconds or so (limited to 250 rows). Have you heard of performance issues related to a large number of SC widgets?

[Isomorphic]

No problem with the described number of components, your application would still be considered small by our standards.

However, for fastest start time, it always makes sense to defer component creation until the components are needed. So be sure you are, eg, using the TabSelected event to create the components in each tab only when the user navigates to that tab.

As samples such as Live Grid demonstrate, you should not be seeing performance degradation at 500 rows in any browser. This suggests you may have disabled incremental rendering via setting setShowAllRecords(true).

[ron.lawrence]

We do use

		grid.setShowRecordComponents( true );
		grid.setShowRecordComponentsByCell( true );

due to some custom buttons in the grid (e.g. http://www.smartclient.com/smartgwt/showcase/#featured_grid_cell_widgets)
This example shows:

         countryGrid.setShowRecordComponents(true);          
         countryGrid.setShowRecordComponentsByCell(true);  
         countryGrid.setCanRemoveRecords(true);  
   
         countryGrid.setWidth(550);  
         countryGrid.setHeight(224);  
         countryGrid.setShowAllRecords(true);

Although we don't have "setShowAllRecords" set to true in our application.

Are custom cell buttons and this setting incompatable?

[Isomorphic]

recordComponents are expensive. If you're just using them for buttons, consider just using a column of type "icon" instead. If you must use them and the dataset is large, use pooling.

setShowAllRecords(true) forces all rows to render instead of rendering just the rows that are visible, so it's incompatible with larger datasets, and also forces all record components to be created up front and effectively forces pooling off. Basically, don't use this setting except in very special circumstances.