1. #71
    Sencha - Ext JS Dev Team Phil Guerrant's Avatar
    Join Date
    May 2011
    Location
    Colorado
    Posts
    322
    Vote Rating
    87
    Phil Guerrant is just really nice Phil Guerrant is just really nice Phil Guerrant is just really nice Phil Guerrant is just really nice Phil Guerrant is just really nice

      3  

    Default


    Quote Originally Posted by jchau View Post
    1) DOM generated in IE7/IE8 can be greatly optimized by reducing number of table elements. Divs used in 3.4 are now replaced with table wrappers. This is very evident in form fields.
    2) Layout engine seems to calculate layout more often than needed.
    1. We've been down this road several times, and have come to the conclusion that performing layout calculations in JavaScript is always more expensive than achieving the same result with pure HTML/CSS. The tables you see in the markup are to achieve layout results that would otherwise require calculation in JavaScript.
    2. Good point. we realize that the layout engine sometimes measures dom elements and performs calculations when not needed. This is on the roadmap for further improvement in Ext JS next.
    Phil Guerrant
    Ext JS - Development Team

  2. #72
    Ext JS Premium Member
    Join Date
    Apr 2008
    Posts
    378
    Vote Rating
    37
    rich02818 is on a distinguished road

      0  

    Default


    @Phil, so you're saying that the additional use of tables in v4 vs v3.4 should be *faster* than the divs (and required calculations?) used in v3.4? Then why is v4 slow much slower than v3.4 ?

    Does the roadmap for further improvement still contain the often stated requirement to regain at least all the performance that was lost in moving from v3 to v4?



    Quote Originally Posted by Phil Guerrant View Post
    1. We've been down this road several times, and have come to the conclusion that performing layout calculations in JavaScript is always more expensive than achieving the same result with pure HTML/CSS. The tables you see in the markup are to achieve layout results that would otherwise require calculation in JavaScript.
    2. Good point. we realize that the layout engine sometimes measures dom elements and performs calculations when not needed. This is on the roadmap for further improvement in Ext JS next.

  3. #73
    Sencha - Ext JS Dev Team Phil Guerrant's Avatar
    Join Date
    May 2011
    Location
    Colorado
    Posts
    322
    Vote Rating
    87
    Phil Guerrant is just really nice Phil Guerrant is just really nice Phil Guerrant is just really nice Phil Guerrant is just really nice Phil Guerrant is just really nice

      6  

    Default


    Rich, Ext JS 4 is slower than 3 because it does a lot more. As discussed earlier in this thread, is a certain amount of overhead associated with the class system, and the layout system is more capable that v3, which results in more (expensive) DOM reads/writes. Using tables in some places is a strategy to reduce the amount of calculation necessary, but it is by no means a magic bullet for achieving speed == v3.

    Rather than try to defend why Ext JS 4 is slower (I think we all realize that) I'd like to share some of our ideas for speeding it up going forward.

    1. Stop doing needless DOM reads to obtain element measurements. Currently there are quite a few cases where components publish their content size for use by the layout system, even if that size is never used by a layout. Our plan is to start tracking the "consumers" of each given component's dimensions so that we can stop reading the DOM to obtain these sizes unless absolutely necessary. Since DOM i/o is the major bottleneck in the layout system, we expect to see some noticeable gains here.
    2. Speed up "re-layout" when a container is resized by only rerunning the necessary layouts. For example, currently when the viewport is resized, it triggers a layout of every child container/component all the way down the hierarchy. We need to be smarter about this, and only relayout the items that need it. e.g. shrink wrapped children can opt out of relayout when their parent is resized. This won't help with initial layout, but it should help to make applications respond a bit more quickly to resize events.
    3. Can't say for sure if we'll have time for this one, but we've talked about the possibility of creating flyweight form fields for speeding up rendering of large forms. The fact that each form field is a component instance that has the full component lifecycle is problematic when you have hundreds of fields in a form.
    4. and finally there's always room for more micro optimizations to squeeze more performance out of the framework. A bunch of very small performance gains could add up to a larger one.

    Our ultimate goal, as often stated before, is to be as fast as Ext JS 3, and we believe that the above items can help us move toward that goal. Whether they get us all the way there remains to be seen, but I'm optimistic we can get close.
    Phil Guerrant
    Ext JS - Development Team

  4. #74
    Sencha User
    Join Date
    Aug 2013
    Posts
    1
    Vote Rating
    0
    samchung11 is on a distinguished road

      0  

    Default


    nice

  5. #75
    Ext JS Premium Member devtig's Avatar
    Join Date
    Jan 2010
    Location
    Rotterdam, The Netherlands
    Posts
    392
    Vote Rating
    13
    devtig will become famous soon enough

      2  

    Default What's in a number

    What's in a number


    What's in a number? What's special about 5? Transition the product from 4 to 5 should be done because of marketing or commercial considerations.

    I expect improvements to the product are done regardless of the version the product lives in.

    In other words. The speed of evolution of ExtJS should not be influenced by the number of version the product lives in.

  6. #76
    Sencha User
    Join Date
    Sep 2010
    Posts
    27
    Vote Rating
    2
    Alinanila is on a distinguished road

      0  

    Default


    Quote Originally Posted by devtig View Post
    What's in a number? What's special about 5?
    For me, the special thing is that Ext 3.x is supported until 12 months after release of 5.0 ... might be interesting for everybody (like us) who is still on Ext 3.x as migration is quite painful for large applications.

    For details, read: https://www.sencha.com/legal/support...ces-agreement/

  7. #77
    Ext JS Premium Member
    Join Date
    Apr 2008
    Posts
    378
    Vote Rating
    37
    rich02818 is on a distinguished road

      0  

    Default


    Quote Originally Posted by Alinanila View Post
    For me, the special thing is that Ext 3.x is supported until 12 months after release of 5.0 ... might be interesting for everybody (like us) who is still on Ext 3.x as migration is quite painful for large applications.

    For details, read: https://www.sencha.com/legal/support...ces-agreement/
    Migration from ExtJS 3 is *impossible* for apps that need the performance problems introduced in version 4 fixed.

  8. #78
    Ext JS Premium Member devtig's Avatar
    Join Date
    Jan 2010
    Location
    Rotterdam, The Netherlands
    Posts
    392
    Vote Rating
    13
    devtig will become famous soon enough

      2  

    Default


    I am tempted to believe that bad performing ExtJS 4 apps are build by people who do a better job complaining (on this forum) then they do a job programming with ExtJS 4.

    Ask yourself if it might by yourself that is not performing well with ExtJS 4

  9. #79
    Sencha User
    Join Date
    Sep 2010
    Posts
    27
    Vote Rating
    2
    Alinanila is on a distinguished road

      0  

    Default


    Quote Originally Posted by rich02818 View Post
    Migration from ExtJS 3 is *impossible* for apps that need the performance problems introduced in version 4 fixed.
    Who said that we depend on those "performance fixes" - "large" app does not automatically mean "slow" app...

    We just need several months of manpower to migrate all that stuff... and company decisions may - not just in our case - be based on dates and facts, which means: ExtJS 5 release date.

    @devtig: Agree!

  10. #80
    Sencha User mysticav's Avatar
    Join Date
    Mar 2007
    Location
    Mexico
    Posts
    478
    Vote Rating
    5
    mysticav is on a distinguished road

      1  

    Default


    I just want 4.2.2, since 4.2.1 has critical blocker bugs.
    Using Ext with cachefly
    Working on LAMPExt