1. #1
    Sencha User
    Join Date
    Jun 2009
    Posts
    750
    Vote Rating
    0
    meroy is on a distinguished road

      0  

    Default Rendering performance of Ext JS compared

    Rendering performance of Ext JS compared


    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.

    Code:
    // 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.

    Code:
    // 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.

    Code:
    // 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.

    Code:
    // 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

  2. #2
    Sencha User
    Join Date
    Jun 2009
    Posts
    750
    Vote Rating
    0
    meroy is on a distinguished road

      0  

    Default


    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();
    Attached Files

  3. #3
    Sencha User
    Join Date
    Jun 2009
    Posts
    750
    Vote Rating
    0
    meroy is on a distinguished road

      0  

    Default


    Merry Christmas and Happy Holidays to all.

  4. #4
    Sencha User
    Join Date
    Jun 2009
    Posts
    750
    Vote Rating
    0
    meroy is on a distinguished road

      0  

    Default


    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

  5. #5
    Sencha User
    Join Date
    Jun 2009
    Posts
    750
    Vote Rating
    0
    meroy is on a distinguished road

      0  

    Default


    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

    Code:
    // 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.

    Code:
    // 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)

    Code:
    // 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

    Code:
    // Profile (total: 5559 calls)
    
    Function        Calls
    --------------  -----
    getStyle()        448
    canLayout()        60
    getWidth()         13
    getHeight()        19
    doLayout()         60

  6. #6
    jay@moduscreate.com's Avatar
    Join Date
    Mar 2007
    Location
    Frederick MD, NYC, DC
    Posts
    16,353
    Vote Rating
    79
    jay@moduscreate.com is a name known to all jay@moduscreate.com is a name known to all jay@moduscreate.com is a name known to all jay@moduscreate.com is a name known to all jay@moduscreate.com is a name known to all jay@moduscreate.com is a name known to all

      0  

    Default


    wow. Thanks for posting this.

  7. #7
    Sencha User
    Join Date
    Jun 2009
    Posts
    750
    Vote Rating
    0
    meroy is on a distinguished road

      0  

    Default


    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.

  8. #8
    Sencha User
    Join Date
    Jun 2009
    Posts
    750
    Vote Rating
    0
    meroy is on a distinguished road

      0  

    Default


    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.

  9. #9
    Sencha User
    Join Date
    Jun 2009
    Posts
    750
    Vote Rating
    0
    meroy is on a distinguished road

      0  

    Default


    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.

  10. #10
    Sencha - Ext JS Dev Team Animal's Avatar
    Join Date
    Mar 2007
    Location
    Notts/Redwood City
    Posts
    30,502
    Vote Rating
    47
    Animal has a spectacular aura about Animal has a spectacular aura about

      0  

    Default


    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.