FF2x vs IE6 in a grid stress test

[jay@moduscreate.com]

While working for a customer for a mock-up data grid with 52 columns by X rows.

While testing in FF and IE6, we learned that there could be some really big differences.

note: these tests were done locally on a 100MB LAN with only one switch btwn the browser and the host.

http://tdg-i.com/img/extjs/grid_stress_test.swf

[hendricd]

Interesting test. Couple things I noticed and have questions on:

Paging Toolbar: The IE grid returned 7 pages, where FF show 4

Was the resultset JSON, XML... ?

At what point does your profiling start- After/Before Reader complete ?

At what point does your profiling end ?

The reason, I ask is (if it's XML) there known performance differences between $MS XML parser and that of Gecko.

[jay@moduscreate.com]

I should have been more elaborate on how i tested. :)

Paging Toolbar: The IE grid returned 7 pages, where FF show 4
- Eh, it's consistent. the 1000 row grid shows 4 pages in both.

Was the resultset JSON, XML... ?
- JSON

At what point does your profiling start- After/Before Reader complete ?
The timer starts at the moment an item is checked - so it takes into account flushing of the store, then loading. I setup a 'beforeload' listener for the ds for those sequential paging tests, eg: arrows, page jumps, refresh button.

At what point does your profiling end ?
ds.on('load', stop timer, update html).

You may run it yourself, though the stuff coming data back from the internet is a variable in this test. Again, i was on a local LAN so it's very fast - 100 - 200ms response.
http://tdg-i.com/img/customers/mikechabot/gridtest.html

[hendricd]

I'd be interested in seeing a checkpoint comparison at:

beforeload:
this interval: XHR and Reader performace
store: datachanged event
this interval: Gridpanel rendering
load

Then that might shed some more light on the differences. ;)

[pyrolupus]

While testing in FF and IE6, we learned that there could be some really big differences.
I would guess that if you disabled FireBug you'd see even bigger differences. :D

Pyro

[SeaSharp]

I did some local testing at 200 rows. Just a 1 second difference between IE 7 & Firefox (Firebug disabled).

However using a manual stopwatch I do not think your automatic times include the full click to render-finished duration. About 5 seconds of processing time is being ignored somewhere @200 rows on a 2006 vintage Pentium 2.8 Duo.

[jay@moduscreate.com]

correct. it does not take into account the flushing of the table, but it is a great indication of the difference in performance. The goal was not to be 100% nitty gritty acurate, but to test on a constant which i think it does well.


it stops when the ds.load event is fired. it's the only thing i could find that was a good 'stop' for the timer.

[SeaSharp]

correct. it does not take into account the flushing of the table
Hmm. In view of my own project requirements you have got me interested in this 5 second flushing of the table operation. It amounts to 0.5 ms per cell.

[jay@moduscreate.com]

i noticed that going from 1 row to 500 was quicker than giong from 200 -> 500 or even 100-> 500.

this is why this benchmark works i think. You can see exactly what type of combinations can speed things up. :)

[hendricd]

it stops when the ds.load event is fired. it's the only thing i could find that was a good 'stop' for the timer.


That's why the datachanged event was of interest as a checkpoint. It would separate the request/read/store-loading from the rendering. ;)

[dug]

We are evaluating EXT for use in our enterprise product. It looks great in general! We have a requirement to show hundreds, sometimes thousands of columns. Performance here is a big concern. This is the biggest concern we now have with EXT, based on work done with EXT 1.1.1. Some forum postings said grid performance would improve in EXT 2.0. So far, in EXT 2.0 beta1 I do not see that.

I am running IE6 on a new/fast Thinkpad T60P, comparing EXT 1.1.1 to EXT 2.0beta1. I have taken the array-grid sample, and only changed the number of rows from 30 to 500 in the first senario scenario. And changed it from 30 to 1500 rows in the second scenario, and changed from 30 to 5000 rows in the third scenario. Note in real life we'll have a lot more than 5 columns and a lot more verbose data.


Scenario 1: 500 records
Initial load of the grid window: 4 seconds - for either EXT 1.1.1 or EXT 2.0beta1
Moving/reordering a column: 1 second - for either EXT 1.1.1 or EXT 2.0beta1
Resizing a column: 1 second - for either EXT 1.1.1 or EXT 2.0beta1


Scenario 2: 1500 records
Initial load of the grid window:
14 seconds - for EXT 1.1.1
17 seconds - for EXT 2.0beta1

Moving/reordering a column:
7 seconds - for EXT 1.1.1
7 seconds - for EXT 2.0beta1

Resizing a column:
3 seconds - for EXT 1.1.1
5 seconds - for EXT 2.0beta1


Scenario 3: 5000 records
Initial load of the grid window:
75 seconds - for EXT 1.1.1
149 seconds - for EXT 2.0beta1

Moving/reordering a column:
58 seconds - for EXT 1.1.1
73 seconds - for EXT 2.0beta1

Resizing a column:
9 seconds - for EXT 1.1.1
55 seconds - for EXT 2.0beta1

Scrolling is extremely fast in all scenarios, a fraction of a second.

Will the performance for grids improve significantly in the initial formal release of EXT 2.0?

We think the product looks awesome in general. But the grid performance is a real concern for us. Any information you could provide on this would be much appreciated!

[jack.slocum]

One important thing to consider when benchmarking 1.1 vs 2.0 is in 1.1 initial row rendering is done in a timeout. So using a standard timer isn't going to be accurate. An accurate timer would have to end at the LAST call to the grid layout function. These benchmarks are measuring 1.1 initial loading vs 2.0 full loading and rendering.

The performance of rendering 1500 or 5000 records cannot be improved because it is not ext that is the bottleneck , it is the browser layout engine.

The biggest performance boost in 2.0 comes from multiple grids on the same page. In 1.1 it got exponentially slower the more grids you have. In 2.0 the performance is constant.

[mlarese]

this is my exeperience
In our new project we are facing milions of records at the time and we find out that the better way is to show how many columns we like but only few records at the time (20).
Pagination do the rest.
We tryed others ways but with poor results.