Rendering performance of Ext JS compared

[meroy]

Profile Results for Rendering Components

Ext JS Revision 5820 with small patch applied (2nd code block in post)
http://www.extjs.com/forum/showthrea...131#post422131

This is as close to the "initial layout" rendering speed of 3.0.3.
At the same time, close to the layout 2.0 resizing performance.
This is what made my day today. Ext JS 3.1 w/ patch really flys.
The patch is quite small -- take a look (2nd code block in post).
Look at the speed advantage with bufferResize set to true versus false.

// Ext.Container.prototype.bufferResize = true;
// Profile (1886.556ms, 83243 calls)

Function        Calls  Percent  Own Time (ms)
--------------  -----  -------  -------------
getStyle()       2248   16.58%   312.733
getWidth()         40   15.14%   285.568
insertHtml()      180    9.84%   185.652
onResize()         84    6.77%   127.722
setValue()         10    5.59%   105.498
autoSizeTabs()     14    4.99%    94.188
canLayout()       110    4.81%    90.702
doLayout()        110    0.63%    11.878

// Ext.Container.prototype.bufferResize = false;
// Profile (2037.773ms, 87415 calls)

Function        Calls  Percent  Own Time (ms)
--------------  -----  -------  -------------
getStyle()       2864   16.37%   333.675
getWidth()         40   14.13%   287.841
canLayout()       204   13.90%   283.234
insertHtml()      180    9.14%   186.258
onResize()         88    6.32%   128.703
setValue()         10    5.22%   106.429
autoSizeTabs()     14    0.67%    13.722
doLayout()        204    0.57%    11.651

Ext JS Revision 5778 with layout 2.0 code (11th zip file from Nige)

Although resizing is nice, component rendering is slow. It's coming
from the changes made to the canLayout function. I will run the same
tests following this using the canLayout logic seen in SVN 5820.
Let's begin with bufferResize set to true and afterwards set to false.
It's the same number of overall calls whether bufferResize is set
to true or false.

Compare this set the those above. It's very interesting.

// Ext.Container.prototype.bufferResize = true;
// Profile (2412.633ms, 86171 calls)

Function        Calls  Percent  Own Time (ms)
--------------  -----  -------  -------------
getStyle()       2600   21.23%   512.245
getWidth()         40   12.09%   291.702
canLayout()       120   11.19%   269.931
insertHtml()      190    7.98%   192.419
onResize()         88    5.54%   133.661
setValue()         10    4.91%   118.461
autoSizeTabs()     14    3.87%    93.454
doLayout()        120    0.58%    14.108

// Ext.Container.prototype.bufferResize = false;
// Profile (2404.014ms, 86171 calls)

Function        Calls  Percent  Own Time (ms)
--------------  -----  -------  -------------
getStyle()       2600   21.13%   508.065
getWidth()         40   12.15%   292.108
canLayout()       120   11.15%   268.152
insertHtml()      190    7.94%   190.941
onResize()         88    5.50%   132.220
setValue()         10    5.03%   120.873
autoSizeTabs()     14    3.87%    92.797
doLayout()        120    0.58%    13.975

Ext JS Revision 5778 with layout 2.0 code (11th zip file from Nige)

This time, using the same canLayout logic as seen in SVN 5820.
Again, no change on whether bufferResize is set to true or false.
This is still not able to beat the first test results in which
bufferResize set to true was beneficial above.

// Ext.Container.prototype.bufferResize = true;
// Profile (1975.994ms, 86171 calls)

Function        Calls  Percent  Own Time (ms)
--------------  -----  -------  -------------
getStyle()       2600   20.23%   399.672
getWidth()         40   14.35%   283.570
insertHtml()      190    9.40%   185.749
onResize()         88    6.35%   125.471
setValue()         10    5.21%   102.860
autoSizeTabs()     14    4.65%    91.974
canLayout()       120    4.22%    83.307
doLayout()        120    0.69%    13.705

// Ext.Container.prototype.bufferResize = false;
// Profile (1961.562ms, 86171 calls)

Function        Calls  Percent  Own Time (ms)
--------------  -----  -------  -------------
getStyle()       2600   20.29%   398.052
getWidth()         40   14.33%   281.080
insertHtml()      190    9.46%   185.560
onResize()         88    6.45%   126.438
setValue()         10    5.31%   104.182
autoSizeTabs()     14    4.64%    90.978
canLayout()       120    4.27%    83.773
doLayout()        120    0.66%    13.040

Ext JS Revision 3.0.3

Look at how much faster canLayout is here. This to me explans one
reason why 3.0.3 renders faster. Nearly 1/10th of a second is due
to this when looking at the first test results above.

As with the first test results, setting bufferResize to true is
beneficial.

// Ext.Container.prototype.bufferResize = true;
// Profile (1694.389ms, 94466 calls)

Function        Calls  Percent  Own Time (ms)
--------------  -----  -------  -------------
getStyle()       1668   19.41%   328.886
getWidth()         60   15.92%   269.721
insertHtml()      180   10.99%   186.250
setValue()         10    5.78%    97.994
autoSizeTabs()     14    5.39%    91.350
doLayout()        110    0.22%     3.792
canLayout()       110    0.02%     0.396

// Ext.Container.prototype.bufferResize = false;
// Profile (1795.839ms, 99956 calls)

Function        Calls  Percent  Own Time (ms)
--------------  -----  -------  -------------
getStyle()       2106   28.56%   512.819
getWidth()         78   13.96%   250.665
insertHtml()      180   10.39%   186.516
setValue()         10    5.40%    97.019
autoSizeTabs()     14    0.51%     9.123
doLayout()        228    0.12%     2.101
canLayout()       228    0.04%     0.649

[meroy]

Utilizing the test case tool release 4

Firefox 3.5.6 Firebug Profiler Results
Macbook Pro 2.4 GHz, Leopard 10.5.8

console.profile();
addForm(0, tabPanelOne, 10); // forms with Html Editor
console.profileEnd();

[meroy]

Merry Christmas and Happy Holidays to all.

[meroy]

Please note that the layout 2.0 results above were from the 11th zip file I received from @Animal on December 14th and do not speak for the current development.

What's interesting here is that the first test results comes very close to the 3.0.3 rendering speed for rendering components. Also amazingly is that the small diff takes resizing performance on par with the layout 2.0 logic. Such a small diff -- 2 lines -- that's it just for this. The other lines are for helping apps better succeed during migration to 3.1.

@dev team: Please take a look at canLayout, especially when applying the layout 2.0 code later on.

I hope that this was helpful. Please ensure the 3.1.x will remain fast, especially on initial rendering of components.

Thank you,
Mario

[meroy]

Profile Results for Maximizing Window

Examples/layout-browser/layout-browser.html

Combination Examples
-->Tabs with Nested Layouts
-->Inner Tab 2
-->Nested Grid

At this point, enable profiling, maximize the window and then stop profiling.

When looking at this, look at the total number of calls.

First up is Ext JS Revision 5820

// Profile (total: 3797 calls)

Function        Calls
--------------  -----
getStyle()        628
canLayout()        60
getWidth()         12
getHeight()        18
doLayout()         60

Next, is Ext JS Revision 5820 with small patch applied (2nd code block in post)
http://www.extjs.com/forum/showthrea...131#post422131

Look how close to the layout 2.0 as far as the total number of calls.

The small diff provides 5820 the resizing performance of layout 2.0
without removing the sheer rendering performance due to buffering.
See first post up thread.

// Profile (total: 2911 calls)

Function        Calls
--------------  -----
getStyle()        508
canLayout()        32
getWidth()          9
getHeight()        15
doLayout()         32

Next, is Ext JS Revision 5778 with layout 2.0 code (11th zip file from Nige)

// Profile (total: 2743 calls)

Function        Calls
--------------  -----
getStyle()        508
canLayout()         0
getWidth()          9
getHeight()        15
doLayout()          0

Finally, the results for Ext JS 3.0.3

// Profile (total: 5559 calls)

Function        Calls
--------------  -----
getStyle()        448
canLayout()        60
getWidth()         13
getHeight()        19
doLayout()         60

[jay@moduscreate.com]

wow. Thanks for posting this.

[meroy]

Yeah, that small diff http://www.extjs.com/forum/showthread.php?t=88546, specifically the 2 line changes to Container.js, will help Ext JS - Air driven apps as well. I did the maximize window test under Safari. The getComputedStyle function was called 573 times. That number dropped down to 477 with that patch.

[meroy]

During my time off and in between visiting family and friends, I've made time to look at Ext 2.3.0's amazingly and super fast rendering engine. I started using Ext JS 3.0.0 a few months back and had no idea on how fast 2.3.0 renders components.

Anyway, it was during this time I continued research on a different path for maximizing both rendering of components and the resizing of the window. It's very nice to finally see Safari's browser window follow my mouse, during resizing, no matter how fast I moved the mouse for the portal/portal.html demo. Folks running this test on a fast machine may not see the benefit unless running on something slower such as a 2.4 GHz laptop.

1. The rendering of components, speed wise, is nothing like Ext 2.3.0. Therefore, the goal here was to take the trunk and get it to render as fast as 3.0.3. It's now even closer and under .05 seconds compared to 3.0.3 during benchmarking -- sometimes faster.

2. At the same time, take resizing to the same performance level as seen by the layout 2.0 code.

I think buffering is still very helpful and fear that this will be taken out of Ext JS. There are apps out there that are very complex. The bufferResize option in Ext JS is beneficial for these apps. Currently, there's talk of the layout storm. So, it defeats the purpose until now as the layout storm has been greatly reduced or eliminated.

The buffering logic was preserved to some degree (pulled back just a few lines that were removed between 3.0.3 and 3.1.0). Also, I pulled one line from Ext 2.3.0. I guess nobody knew the delta for changing that line in the first place due to not benchmarking at the time -- I'm not sure.

I will post the small patch set after completing additional testing. Folks will be able to choose on whether they want to disable buffering (as fast as layout 2.0) or with buffering (faster) and see things like Safari, during resizing of a complex demo, follow the mouse no matter how fast I move it. The key to this was the one line taking from Ext 2.3.0.

The new patch has improved and the number of calls during profiling is now as low as the layout 2.0 logic when maximizing the window.

Developers and contributors all had awesome ideas for the code that went into making Ext JS 2.x to 3.x. The patch helps ties some of this together by restoring a few lines from 3.0.3, a line from 2.3.0 and a couple lines from the layout 2.0 logic which compliments the layout changes introduced in SVN 5691.

Stay tuned for the patch and results. The patch is actually quite small.

[meroy]

Testing has been going well. I will post the patch and results tonight after work. Only IE 6 and FF 3.0.16 remains for testing now. IE 7, IE 8, FF 3.5.6 (Leopard & Windows), Safari 4.0.4 (Leopard & Windows) and Opera 10.10 have passed.

[Animal]

FYI, core dev Jamie Avins is actively working on the layout engine. I have handed him my very experimental code with the rendering and laying out code split into two optional operations.

I have also handed him the performance monitoring class which counts DOM modifications so that he can find the best code path to optimize rendering.

It will be very interesting to see what emerges when someone is able to work full time on this.