[OPEN] [EXTJSIV-1952] Performance Comparison between Ext 3.2.1 and Ext 4.0

[Mark879]

Performance Issues with ExtJS 4.0

I have put together my findings for three different examples and found that performance has increased in some areas and decreased in other areas. I have tested using four different browsers: Internet Explorer 8, Internet Explorer 9, Firefox 3.6, and Google Chrome 10.06. I have also tested against three different versions of ExtJs, 3.2.1, 4.0 Preview 5, and 4.0 GPL.


I would like to know why the first example (the easiest) performs so slowly in ExtJs 4.0.


I used a stopwatch javascript timer to gather these numbers. The examples and full write-up are in the attached zip file.



Example 1 – Form Example

In a SenchaCon video entitled ‘ExtJS 4.0 Layout System’, one of the developers mentioned there were massive performance improvements. The example he used was a simple form with 500 text fields on it. We recreated this example in-house and did NOT notice a performance improvement. In fact, we noticed a performance decrease.

This example contains a window with a form inside, and inside the form there are 500 text fields. When the page loads, the window will show.


example1.png

Rendering time:


3.2.1
IE8: 5.72 secs
IE9: 0.878 secs
FF3.6: 9.295 secs
Chrome 10.06: 1.281 secs

4.0pr5
IE8: 18.023 secs
IE9: 5.032 secs
FF3.6: 37.525 secs
Chrome 10.06: 13.522 secs

4.0
IE8: 13.17 secs
IE9: 1.738 secs
FF3.6: 7.575 secs
Chrome 10.06: 0.070 secs


Example 2 – Complex Layout Example
In this use-case we attempted to model one of our more complex layouts using the ExtJS 4.0 framework. This form contains a tab panel, various sub-panels, layouts, fields, grids, and buttons.

example2-smaller.png
Rendering time:

3.2.1
IE8: 2.27 secs
IE9: 0.601 secs
FF3.6: 4.684 secs
Chrome 10.06: 0.817 secs

4.0pr5
IE8: 7.043 secs
IE9: 1.444 secs
FF3.6: 4.396 secs
Chrome 10.06: 1.532 secs

4.0
IE8: 2.572 secs
IE9: 1.522 secs
FF3.6: 4.669 secs
Chrome 10.06: 1.262 secs



Example 3 – Grid example
For this example, we took a grid from the ExtJS 4.0 examples page and a grid from the ExtJS 3.0 examples page and did a comparison.

example3-smaller.png
Rendering time:




3.2.1
IE8: 1.026 secs
IE9: 0.237 secs
FF3.6: 1.894 secs
Chrome 10.06: 0.660 secs

4.0pr5
IE8: 7.598 secs
IE9: 0.840 secs
FF3.6: 3.866 secs
Chrome 10.06: 1.038 secs

4.0
IE8: 0.458 secs
IE9: 0.123 secs
FF3.6: 0.249 secs
Chrome 10.06: 0.112 secs

[rich02818]

IMHO this issue is of paramount importance. The number 1 stated benefit of 4.0 is increased performance. Sencha has noted that 3.x increased flexibility, but decreased performance from 2.x. If 4.0 is not faster than 3.x in real world scenarios, then something is very wrong. This issue should take precedence over all the ongoing effort to fix individual problems as it won't matter if 4.0 remains slower than 3.x.

[aconran]

Mark & Rich -

Performance of Ext is of 'paramount importance' as you noted. We are actively working on improving the performance wherever possible. Thanks to the community who has pointed out certain cases where the performance is lower than prior versions.

When we are doing our profiling each test/use case may have different implications and performance metrics associated with it. For example in your test case #3 regarding the grid. The grid was:
2x faster in IE8
2x faster in IE9
8x faster in FF3.6
6x faster in Chrome 10

when using Ext 4.0.0. We are happy to see these numbers. However, some other customers have brought up the fact that the grid's performance may degrade under certain cases like when you have many columns (40+) or when it is in a certain deeply nested layout configuration. Each time you contribute one of these edge case examples, we can profile against them and they become an integrated part of our metrics.

In the next 4.0.1 release you will see that both of these cases pointed out to us (where you have many columns or you are in deeply nested layouts) the performance has been drastically improved.

[rich02818]

Aaron,

In the next 4.0.1 release you will see that both of these cases pointed out to us (where you have many columns or you are in deeply nested layouts) the performance has been drastically improved.

It is *not* only such cases where 4.0 is significantly slower than 3.x. Mark showed that a simple form with many fields is also. In fact, other than the grid examples you mentioned, I've yet to see anything where 4.0 is not slower than 3.x and I've explicitly asked for just such examples previously. In another post a week ago I stated that the 'themes' demo with only the htmleditor present is slower to load in 4.0 than the entire themes demo in 3.3.3. The problem is not restricted to complex layouts or many columns in a grid....

Very much looking forward to 4.0.1. I hope it addresses the many other cases beyond those you mentioned in this post.

Thanks.

[aconran]

Thanks for the feedback Rich. We're looking into various problems that have been pointed out.

[rich02818]

Thanks for the feedback Rich. We're looking into various problems that have been pointed out.

Glad to hear that. I spent many years developing embedded, safety-critical, hard real-time systems so I'm quite sympathetic to the efforts needed regarding performance.

Several days ago NoahK17 wrote:

Also experience performance issues in IE 7/8/9 compared to Firefox and Chrome.

I am using a Viewport where the Center region is outputting HTML. When I show 6k rows in a table format, Firefox and Chrome handle it fine... but IE slows to a halt.

But it only slows to a halt when the table is displayed INSIDE of the center region. If I just display the HTML with no ExtJS 4 wrapper, it works fine. So there's something within Ext 4 that is crippling rendering time in IE browsers.

Good luck tracking down the issue!

This would be a very interesting place to look as it seems to imply that just loading html into a border region is causing something within ExtJS to execute repeatedly and causes signficant issues in IE...I'd guess that some event handler(s) are running. If so, this may be the culprit also with the html generated by ExtJS components.

[aconran]

This would be a very interesting place to look as it seems to imply that just loading html into a border region is causing something within ExtJS to execute repeatedly and causes signficant issues in IE...I'd guess that some event handler(s) are running. If so, this may be the culprit also with the html generated by ExtJS components.

I went down this road a bit and thought it may have to do with CSS and changing the box sizing. I however could not repro the same results. I've been in contact with Noah over PM and am trying to get a concrete example that shows a possible problem.

[rich02818]

Aaron, any progress with this yet? Thanks.

I went down this road a bit and thought it may have to do with CSS and changing the box sizing. I however could not repro the same results. I've been in contact with Noah over PM and am trying to get a concrete example that shows a possible problem.

[Animal]

How did you make those measurements?

It would be difficult to do for me because I don't have a Windows machine here, only VMs.

But in the past few days we've solved some really severe bottlenecks in layout code which will speed up both initial render and laying out of components.

[dzj]

How did you make those measurements?

It would be difficult to do for me because I don't have a Windows machine here, only VMs.

But in the past few days we've solved some really severe bottlenecks in layout code which will speed up both initial render and laying out of components.

why don't use a windows machine to develop and test?