GridPanel performance improvement

[shiweiwei97]

Hi guys,

I open this thread to share some experience of addressing GridPanel's performance problem and discuss if ExtJs team can make some changes in the library itself. We use GridPanel to display a 9-column table, with 500 records per page at max. When user resizes the browser or switches from one tab to another, the browser freezes for at least 10 seconds. When I looked into this problem, I found that the freeze time is directly related to the record count. When the grid is empty, the resizing is quite fast. So I came up with the following approach:
1. apply a filter to grid before resizing so that the grid will be empty.
2. after resizing, clear the filter and render the records into grid.
With these changes, we reduce the time cost to 3-4 seconds (still a little slow to be frank). But comparing to the original application, that is a big improvement.

restrictions:
The grid will always go to the first record after resizing.

I am open to any comments for this solution and I would like to learn from ExtJs team if this can be an option of GridPanel.
Thanks.

[mlarese]

if you use pagination there is no need to show 500 records at the time. Facing the same problem we solved it using 20 records and every thing is very quick.

[shiweiwei97]

I am using pagination actually and have recommended reducing the page size but users insisted on having 500 records per page.


if you use pagination there is no need to show 500 records at the time. Facing the same problem we solved it using 20 records and every thing is very quick.

[mlarese]

so the problem that the grid is slow is less important than to have 500 records?
I don't understend why they need such amount of data. the only way is to use livegrid
http://www.extjs.com/forum/showthread.php?t=17791

I tryed my self to speed up the grid, but when the amount of records is high no way, the only solution is to limit the records.

[joeri]

A possible grid implementation that wouldn't suffer from this is how flex does it: render only as many rows as fit on the screen, and fill them up / reposition them depending on the user's scroll position.

Doing this you would lose ctrl-f support though. You'd also have to fake the scrollbar.

[SeaSharp2]

Was your grid testing based on Ext 2.2? The release notes for 2.2 refer to a new deferred rendering behavior.

[shiweiwei97]

Was your grid testing based on Ext 2.2? The release notes for 2.2 refer to a new deferred rendering behavior.
I am using Ext 2.0.1. I tried Ext 2.2 in my app. Unfortunately it didn't make any difference. In the release note of 2.2, it says the deferred rendering is enabled by default. So I think I do not need to make any changes other than switching to version 2.2.

[shiweiwei97]

so the problem that the grid is slow is less important than to have 500 records?
I don't understend why they need such amount of data. the only way is to use livegrid
http://www.extjs.com/forum/showthread.php?t=17791

I tryed my self to speed up the grid, but when the amount of records is high no way, the only solution is to limit the records.

We develop the website to replace the legacy ASP one. It used a large page size because users don't want to switch between pages frequently. Of course 500 rows is not a big issue to basic HTML table. And from a user's perspective reducing the page size means more page turning.

I tried the livegrid demo. It is a good alternative to GridPanel, but I need to see if users can accept losing the Ctrl+F ability.

[ThorstenSuckow]

I tried the livegrid demo. It is a good alternative to GridPanel, but I need to see if users can accept losing the Ctrl+F ability.

Well, you're still losing ctrl-f functionality in a paged grid, right? You can try and set the buffer size of the livegrid to the actual number of records in your datastore. Tests have shown that javascript has not a big problem keeping 5000+ records in the memory, as long as not all of that 5000+ records are rendered at once (heavy DOM operations slowing down the client).

So I suggest: Try out the livegrid with the above mentioned settings. And as far as I see it, the deferRowRenderer setting in Ext 2.2 is nothing more but a setting to defer initial rendering of the rows when the grid is shown on the page, i.e. this does to apply for single row rendering.

[euchiyama]

I had a similar issue when I implemented a "Show All" option in the grid column menu...with 20-30 columns.

In my column menu override, my solution was to:
make a temp copy of the Data Store
set the Grid to a blank Data Store
implement the "Show All" logic...rendering each column
set the Grid Data Store back to the originalThe improvement was AMAZING...

[shiweiwei97]

Well, you're still losing ctrl-f functionality in a paged grid, right? You can try and set the buffer size of the livegrid to the actual number of records in your datastore. Tests have shown that javascript has not a big problem keeping 5000+ records in the memory, as long as not all of that 5000+ records are rendered at once (heavy DOM operations slowing down the client).

So I suggest: Try out the livegrid with the above mentioned settings. And as far as I see it, the deferRowRenderer setting in Ext 2.2 is nothing more but a setting to defer initial rendering of the rows when the grid is shown on the page, i.e. this does to apply for single row rendering.

Regarding the Ctrl+F functionality, I implemented a function similar with Firefox's Ctrl+F on GridPanel toolbar. I am not sure if I can still keep this in LiveGrid.

I agree rendering a small amount of records and having others in memory is the right way out. But I will fully test if using LiveGrid will affect the existing functionalities in my application.

[shiweiwei97]

I had a similar issue when I implemented a "Show All" option in the grid column menu...with 20-30 columns.

In my column menu override, my solution was to:
make a temp copy of the Data Store
set the Grid to a blank Data Store
implement the "Show All" logic...rendering each column
set the Grid Data Store back to the originalThe improvement was AMAZING...
I applied a similar change in my app using filterBy/clearFilter functions of GridPanel. But are you able to keep the scroll position as the grid refreshes after restoring data store?
In my app, maybe the page size is too big (500 rows, 9 columns). This fix helps but is not good enough.

[mlarese]

500 x 9 = 4500 cells ... And you ask why is so slow.
Limit the amount of data and you will solve the problem. You can try different types of grids from different frameworks and the result will be the same. As you can see nobody as a different solution (live grid too limit the amount of rows). You want more speed without change anything you did before, if you don't change anything nothing will change in speed. There is no magic solution sorry.

[shiweiwei97]

500 x 9 = 4500 cells ... And you ask why is so slow.
Limit the amount of data and you will solve the problem. You can try different types of grids from different frameworks and the result will be the same. As you can see nobody as a different solution (live grid too limit the amount of rows). You want more speed without change anything you did before, if you don't change anything nothing will change in speed. There is no magic solution sorry.
500 rows per page is required by users and there is no clear reason:(

I have tried LiveGrid in my application and modified the PagingToolbar a little bit so that I can use pagination in LiveGrid. The performance is improved significantly as it only renders the visible rows (20-30 rows, depends on the display settings). For basic usage of GridPanel, LiveGird is a nice solution.

However, LiveGrid does have some restrictions in my experience.
1. Data store's filter related functions are not available but it can be resolved with a server-side filter function.
2. EnableRowBody option is not supported as it calculates the total height based on fix row height.
3. GroupingView is not supported for the same reason as 2.

[ashly.jos@gmail.com]

I had a similar issue when I implemented a "Show All" option in the grid column menu...with 20-30 columns.

In my column menu override, my solution was to:
make a temp copy of the Data Store
set the Grid to a blank Data Store
implement the "Show All" logic...rendering each column
set the Grid Data Store back to the original
The improvement was AMAZING...

Hi,

Can you please share the piece of code where you have done this.

I tried the below and it does not improve the performance. Am I doing something wrong here?


//Temp store
PagingModelMemoryProxy tempProxy = new PagingModelMemoryProxy(new ArrayList<Advert>());
PagingLoader<PagingLoadResult<ModelData>> tempLoader = new BasePagingLoader<PagingLoadResult<ModelData>>(tempProxy);
advertStore = new ListStore<Advert>(tempLoader);
advertGrid.reconfigure(advertStore, cm);


// Actual data
proxy = new PagingModelMemoryProxy(adverts);
loader = new BasePagingLoader<PagingLoadResult<ModelData>>(proxy);
loader.setRemoteSort(true);
advertStore.removeAll();
pagingToolBar.bind(loader);
loader.load(0, NUMBER_OF_RECORDS_PER_PAGE);
ListStore<Advert> tempListStore = new ListStore<Advert>(loader);

// Assigning to actual store
advertStore = tempListStore;

// Reconfiguring the grid
advertGrid.reconfigure(advertStore, cm);


Thanks,
-ash