restoreScrollState consuming 50% CPU Time on simple grid with grouped headers?

[daubman]

I have a fairly simple sorted Ext.grid.Panel that has a new row added to it every 5 seconds. After a minute or so Firefox (8.0.1) begins to slow down. Firebug's profiler shows that restoreScrollState is consuming ~50% CPU time. It is a low # of calls (once per row addition) however, each call takes ~250ms.

I am wondering:
1) Is this expected?
2) Is there anything I can do to improve this? I suppose I do not want the grid jumping around as data is added, but is there a more efficient way to add a new record to the grid's store (and subsequently display it in the grid)?

I am retrieving JSON from an Ext.data.Connection() (this becomes 'data' in the code example below) - this is run every 5 seconds retrieving a new JSON object in data each time.



...
data = Ext.decode(response.responseText);
...
sstStore.loadRawData(data, true);
lewStore.loadData(sstStore.getRange(), true);


Background:
sstStore is a store with a data-specific model for a specific data source that normalizes the data from this source. There will eventually be more sources that do the source-specific mapping of data to normalized/common format.

lewStore is the store that the grid panel uses. It is the place that all normalized data sources feed into so that all of the data may be viewed together from the disparate data sources.

[mitchellsimoens]

Can I get a locally runnable test case?

[skirtle]

I observed the same phenomenon in 4.1-pr1. In my test case I just resized a grid with lots of cells. I mentioned it to Don, apparently it was already on the radar but it isn't trivial to improve it. Not sure what progress has been made since then.

I made the following override on one of my projects with a large grid. I'm sure there must be some nasty consequences doing this but so far all I've seen is a massive speed boost.


Ext.apply(Ext.view.Table.prototype, {
restoreScrollState: Ext.emptyFn,
saveScrollState: Ext.emptyFn
});

It didn't cause scrollbar issues for me but I'm not adding/removing rows, so maybe that's where the problems would be.

It only really helps on large grids, for small grids the gain is negligible.

[tobiu]

this should already be changed in the SDK build.
-> restoring the scroll state only if there if the grid was scrolled and hopefully saving the scroll state on scroll.

i had no time yet to take a close look on the new implementation, but this was the idea to change it.