1. #1
    Ext User keesje's Avatar
    Join Date
    Jun 2007
    Posts
    3
    Vote Rating
    0
    keesje is on a distinguished road

      0  

    Default Performance TIPS for grid

    Performance TIPS for grid


    As we have screens with multiple grids which had a loading time of 20 seconds (P4-2.4ghz)

    *eleminate calls to updaterule (updaterule is evil )
    -update updaterule to not change the value if the value is already present and the same
    -in the grid do not generaterules for the columns if the rules are present
    -precalc the column width rules and insert them in the stylesheet before creating the grid (first step on init, only possible if you know what you're going to create)
    -change the unhideColumn and hideColumn to use generated ID's instead of updaterule (the updaterule calls in this function can take upto 1 second per grid, now it's less than 100ms)

    *update addstyles to get the currentStyle or getComputedStyle and do not call getstyle

    These optimalisations gave us a new loading time of 9 seconds.

    One thing that is bugging us right now is a getWidth on a div with the x-layout-container class which takes 140-240ms (time is in the offsetWidth call) , unfortunately this is called a few times from the ext framework, so this really adds up. Any idea's ?

    Regards,
    Kees

  2. #2
    Sencha User jack.slocum's Avatar
    Join Date
    Mar 2007
    Location
    Tampa, FL
    Posts
    6,955
    Vote Rating
    17
    jack.slocum will become famous soon enough jack.slocum will become famous soon enough

      0  

    Default


    What you are doing by changing those calls is moving WHERE the delay (the reflow) happens. In turn, accessing a simple property (like offsetWidth) is having the delay instead of in the old spot.

    Let me explain a little further. updateRule causes changes to be reflected immediately (a reflow, which is expensive). Your changes (for example, changing unhide/hideColumn) causes the changes (again, the reflow) to not occur immediately - but they ARE going to happen. There is going to be a reflow to propagate the changes, only it won't be in your timed block. It will happen the first time you access a property (like offsetWidth) which requires an up to date state (hence triggering a reflow and your delays).

    Gridv3 (Ext 2.0) solves these issues in a different fashion and it results in multi-grid performance that is significantly faster (it doesn't matter how many grids you have, unlike Gridv2). I will be writing about it soon.
    Jack Slocum
    Ext JS Founder
    Original author of Ext JS 1, 2 & 3.
    Twitter: @jackslocum
    jack@extjs.com

  3. #3
    Ext User keesje's Avatar
    Join Date
    Jun 2007
    Posts
    3
    Vote Rating
    0
    keesje is on a distinguished road

      0  

    Default


    Quote Originally Posted by jack.slocum View Post
    What you are doing by changing those calls is moving WHERE the delay (the reflow) happens. In turn, accessing a simple property (like offsetWidth) is having the delay instead of in the old spot.

    Let me explain a little further. updateRule causes changes to be reflected immediately (a reflow, which is expensive). Your changes (for example, changing unhide/hideColumn) causes the changes (again, the reflow) to not occur immediately - but they ARE going to happen. There is going to be a reflow to propagate the changes, only it won't be in your timed block. It will happen the first time you access a property (like offsetWidth) which requires an up to date state (hence triggering a reflow and your delays).

    I disagree with this, not the 2.0 part ;-)
    The problem with using updaterule if the HTML is generated is that you need a reflow.
    If you generate the CSS rules before the HTML is present , the HTML will be build correctly the first time, so you do not have a reflow at setting the widths of the columns (you need to know what Ext is going to build beforehand, which can be a problem)
    Updating the stylesheet is also more costly than directly changing an attribute in a style, but has the disadvantage that you cannot rebuilt your HTML without throwing away style, which poses no problem at this time.

    Do you know if there is a performance gain to be had from changing the selector to be more specific: using the element as prefix for the class, or using a generated ID instead of the #id .class construction ?

    About the offsetWidth:
    The offsetWidth of the layout div went up a few 100 ms while the addStyles went down seconds... This is a fair tradeoff, because addStyles is called more often than the offsetWidth of the layout div.

    Offcourse changing column widths afterwards will be just as fast/slow, but this is not initial startup time.

    Regards,
    Kees

  4. #4
    Sencha User jack.slocum's Avatar
    Join Date
    Mar 2007
    Location
    Tampa, FL
    Posts
    6,955
    Vote Rating
    17
    jack.slocum will become famous soon enough jack.slocum will become famous soon enough

      0  

    Default


    If you generate the CSS rules before the HTML is present , the HTML will be build correctly the first time, so you do not have a reflow at setting the widths of the columns (you need to know what Ext is going to build beforehand, which can be a problem)
    It already does that. It generates the rules (which takes no time) before anything is ever rendered to the grid. This is one of the reasons for the 2 part rendering.

    Do you know if there is a performance gain to be had from changing the selector to be more specific: using the element as prefix for the class, or using a generated ID instead of the #id .class construction ?
    I tried this as well. It had no effect at all. The overhead is not updating/propagation of the CSS rules. It is the reflow of absolute positioned elements containing tables with dynamic sizes. Ext 2.0's big performance jump was gained by removing these 2 things and by using inline styles to get it down to 1 reflow per update.


    The offsetWidth of the layout div went up a few 100 ms while the addStyles went down seconds... This is a fair tradeoff, because addStyles is called more often than the offsetWidth of the layout div.
    As I stated in the first post, it's just the timer misinforming you because things are happening behind the scenes. Like, for example, if you look at a profile for rendering and you will see most calls to getStyle take < 1ms. However, there will be a max value in there of 300ms. There is no style that takes 300ms to retrieve, it just caught the browser at a time when it was busy doing something else. Trust me, I have done a crazy amount of time testing and tuning the 2.0 grid and even when completely by-passing addStyles and returning hard-coded test values the overall render time was the same --- except the "perceived bottleneck" had moved to a different function. When you trigger a reflow that reflow may be delayed slightly, if the function you are calling (like addStyles, which is called a lot) happens to get called when the actual reflow occurs, it will erroneously appear to be the bottleneck.

    I have no doubt that changes CAN be made to the v2 grid to help performance, but I thought I would share some of the things I found not to be the bottleneck to save you some time.
    Jack Slocum
    Ext JS Founder
    Original author of Ext JS 1, 2 & 3.
    Twitter: @jackslocum
    jack@extjs.com

  5. #5
    Ext User keesje's Avatar
    Join Date
    Jun 2007
    Posts
    3
    Vote Rating
    0
    keesje is on a distinguished road

      0  

    Default


    Quote Originally Posted by jack.slocum View Post
    It already does that. It generates the rules (which takes no time) before anything is ever rendered to the grid. This is one of the reasons for the 2 part rendering.
    We're pre-generating the rules for all the grids with the width info before any rendering is done on the page. So adding these CSS rules cause no reflow of the elements because there aren't any to reflow.
    After that the Grid builds and renders correctly using to the pregenerated rules. The updaterule has been optimized to ignore existing values, so it causes no reflows, and still works when we're not pre-generating.
    In other words: updatecolumns causes no reflow with our code because it renders correct the first time around.
    This optimalisation is very noticable: init times from 20 to 10 seconds. This is not perceived time ;-)


    Setting the style.display directly on the elements seems to be alot faster than updaterule, I have to do some extra logging to .



    Quote Originally Posted by jack.slocum View Post
    I tried this as well. It had no effect at all. The overhead is not updating/propagation of the CSS rules. It is the reflow of absolute positioned elements containing tables with dynamic sizes. Ext 2.0's big performance jump was gained by removing these 2 things and by using inline styles to get it down to 1 reflow per update.
    Looking forward to it...

    Quote Originally Posted by jack.slocum View Post
    As I stated in the first post, it's just the timer misinforming you because things are happening behind the scenes. Like, for example, if you look at a profile for rendering and you will see most calls to getStyle take < 1ms. However, there will be a max value in there of 300ms. There is no style that takes 300ms to retrieve, it just caught the browser at a time when it was busy doing something else. Trust me, I have done a crazy amount of time testing and tuning the 2.0 grid and even when completely by-passing addStyles and returning hard-coded test values the overall render time was the same --- except the "perceived bottleneck" had moved to a different function. When you trigger a reflow that reflow may be delayed slightly, if the function you are calling (like addStyles, which is called a lot) happens to get called when the actual reflow occurs, it will erroneously appear to be the bottleneck.

    I have no doubt that changes CAN be made to the v2 grid to help performance, but I thought I would share some of the things I found not to be the bottleneck to save you some time.
    In addstyles there is a performance gain to be had because you can avoid "catching the browser at a bad time" twice, this is not only firebug time we're talking about, this was the first optimalisation I did which gave us real results.

  6. #6
    Ext User
    Join Date
    Jun 2007
    Posts
    3
    Vote Rating
    0
    jkwoo is on a distinguished road

      0  

    Default


    Hi Keesje
    Could you show some sample code about how to update addstyles to get the currentStyle or getComputedStyle and do not call getstyle.
    I try to change the code in ext-all-debug.js for addstyles, but fail.

    Thank you

Thread Participants: 2

Turkiyenin en sevilen filmlerinin yer aldigi xnxx internet sitemiz olan ve porn sex tarzi bir site olan mobil porno izle sitemiz gercekten dillere destan bir durumda herkesin sevdigi bir site olarak tarihe gececege benziyor. Sitenin en belirgin ozelliklerinden birisi de Turkiyede gercekten kaliteli ve muntazam, duzenli porno izle siteleri olmamasidir. Bu yuzden iste. Ayrica en net goruntu kalitesine sahip adresinde yayinlanmaktadir. Mesela diğer sitelerimizden bahsedecek olursak, en iyi hd porno video arşivine sahip bir siteyiz. "The Best anal porn videos and slut anus, big asses movies set..." hd porno faketaxi