Hybrid View

  1. #1
    Ext JS Premium Member
    Join Date
    Jul 2010
    Location
    UK
    Posts
    524
    Vote Rating
    29
    MrSparks has a spectacular aura about MrSparks has a spectacular aura about

      0  

    Default 4.x Framework performance – Request for an Official Statement

    4.x Framework performance – Request for an Official Statement


    Michael Mullany - Sencha Employee
    we don’t know exactly how fast 4.1 is going to be, but if you pointed a gun at our heads, we would say it’s likely to still be slower than 3.x. If IE performance is all you care about, and you don’t care about the new features in 4.x and you have to make a decision *today* to go with 4.x vs. stay on 3.x, then we’d probably tell you to stay on 3.x. This might still turn out to be the incorrect recommendation, but if you want our best recommendation for *today* - October 31st 2011 - there it is.
    @Sencha

    I’ve just spotted the above on the 4.1 pr1 blog and it has me incredibly worried and depressed to say the least.

    3.x by Sencha’s own admission performed very poorly and was unacceptable. If 4.x can’t even match the unacceptable performance of 3.x, then I’m really at a loss to see what the point of 4.x was. Quote “JavaScript Framework for Rich Apps in Every Browser” The key words being “apps” and “every browser” here. 4.x absolutely needs to be out-performing 3.x on all browsers to enable developers to produce “real-world” commercial web applications.

    Regarding: “If IE performance is all you care about”. We have no choice other than to care about IE, it has a massive corporate install base and it’s not going away any time soon. Ironically, one of the reasons corporate users are sticking with Windows XP is because newer incantations of Windows have a huge footprint and perform badly on equivalent hardware.

    Guys please tell me this awful news about 4.x isn’t true!

  2. #2
    Sencha User
    Join Date
    Nov 2009
    Location
    Poland
    Posts
    84
    Vote Rating
    2
    saprot is on a distinguished road

      0  

    Default


    The whole new class system etc is really cool, but how many people will actually care if its Ext.define instead of Ext.extend, while it's three times slower?

    Would't it be better if you'd just taken 3.4.0 and improve it, rather than making framework revolution?

  3. #3
    Sencha User
    Join Date
    Mar 2010
    Location
    Bay Area
    Posts
    152
    Vote Rating
    1
    mmullany is on a distinguished road

      0  

    Default


    Guys,

    Let me add another statement, which I'll add to my comment on the blog too. Is that we're not finished with performance optimization with the 4.1 release, we'll continue to improve performance in 4.2 and beyond, and we won't stop until we're happy - which is to say, at least as fast as 3.x.

    -- michael

  4. #4
    Sencha Premium Member
    Join Date
    Sep 2011
    Posts
    48
    Vote Rating
    1
    stahlman is on a distinguished road

      0  

    Default


    Echoing MrSparks' concerns... I found the following post a bit troubling...

    http://www.sencha.com/forum/showthread.php?152195-Overall-Performance/page2#post_665792


    I may be reading too much between the lines, but I got the sense while reading Ed's post that from Sencha's perspective, 4.x is the new baseline against which small incremental performance improvements are to be measured. From my perspective, 4.0 should never have been released. I appreciate and applaud the desire to provide a cleaner, more object-oriented approach to html and the dom, but only insofar as it can be done without significantly impacting performance. Encapsulating messy dom implementation details in an OO cloak can be helpful, but not if I have to spend countless hours rewriting/optimizing what I've developed under the OO paradigm because it's simply too sluggish to be usable by the customer. In my case, I've spent so much time optimizing that I'm thinking I would have been better off time-wise (and certainly performance-wise) writing the whole thing using a more traditional DHTML approach.

    On a philosophical note... I'm beginning to wonder whether the fundamental problem here is that the attempts to encapsulate do not sufficiently recognize the constraints of the underlying implementation (html/dom) being encapsulated. When I was profiling one of my views in Ext 4.0, Chrome and Firefox profilers were showing something on the order of 500 layouts being performed by the browser just to render the initial view! Chrome Speed Tracer flagged this (rightly so) as a problem, even though its rendering engine was sufficiently optimized (or perhaps it was that Ext was sufficiently optimized for Chrome's rendering engine ;-) to render the view without a lot of noticeable delay. But even if, by dint of Herculean efforts, the browser's rendering engine is able to do those ~500 layouts in a reasonable amount of time, the fact that it needs to makes me wonder whether we've taken a wrong turn somewhere... Just because something can be done, doesn't mean it should be. I can't speak for all developers, but from my perspective, I'd be willing to give up a bit of layout configurability/flexibility if it permitted the framework to do things in a manner that was more "natural" - i.e., in a way that didn't seem to be fighting the way the browser works. I'm thinking that if this approach were taken, we'd never see anywhere near 500 layouts for a single view rendering...

    Incidentally, I don't know how many browser layouts are required under 4.1. I'm getting too many rendering errors with it at this point to do much performance testing.

    Sincerely,
    Brett Stahlman

  5. #5
    Ext JS Premium Member
    Join Date
    Jul 2010
    Location
    UK
    Posts
    524
    Vote Rating
    29
    MrSparks has a spectacular aura about MrSparks has a spectacular aura about

      0  

    Default


    @stahlman, excellent post.

    @Sencha
    With regards to other talk of 4.2, beyond and the performance will come. Realistically 4.2 is a year away for a stable release and that's far too long to wait for most dev's and certainly far too long to wait without a rock solid performance promise.

    Comments of at least as fast as 3.x isn't anything to shout about. 3.x is already acknowledge (by Sencha) to be a poor performer, so why on earth would that now be the performance target for 4.x. That makes no commercial/development sense.

    Surly when 4.x was in early alpha / proof of concept, someone at Sencha must have checked to see if it was an improvement over 3.x?

    Whilst researching frameworks for my app, my 3.x proof of concepts showed me that 3.x didn’t quite have enough horsepower for my app, so my commitment (commercial and time investment) in EXT JS and 4.x was based on the fact that 4.x was going to be a huge performance hike over 3.x

    Is the official line on 4.x now that performance won’t be any better that 3.x?

    If that's the case (aside from the absolute nightmare that will cause me of finding a new framework and rewriting my app), what does the future hold for EXT JS. Will 5.x be even bigger and slower 4.x? Based on past major EXT JS framework releases, there's an obvious pattern developing. Where is the line in the sand? There has to be one Guys.

    It honestly pains me to have to post these words because I know how much hard work and person effort the Sencha Devs have put into the framework.

  6. #6
    Ext JS Premium Member
    Join Date
    Nov 2009
    Posts
    233
    Vote Rating
    1
    chinabuffet is on a distinguished road

      0  

    Default


    Great post stahlman... that pretty much sums up what we've been dealing with as well.

    I managed to get a few screens in our app to partially render at least, but it involved numerous hacks to both my app code + the ext source files. For the most part it seemed to be quicker, but some areas just wouldn't render at all so that was probably factoring into it.

  7. #7
    Sencha - Ext JS Dev Team dongryphon's Avatar
    Join Date
    Jul 2009
    Posts
    1,344
    Vote Rating
    134
    dongryphon is a name known to all dongryphon is a name known to all dongryphon is a name known to all dongryphon is a name known to all dongryphon is a name known to all dongryphon is a name known to all

      0  

    Default


    @MrSparks

    Can you (without too much trouble) provide some examples that could help us profile/measure your use case(s) and understand more specifically where you are having performance problems? I know that it may not yet be possible for you to measure on 4.1, but even if the example works in 4.0 and not in 4.1, it would still be very helpful.

    We rely a lot on our own examples, especially the combination examples, but they are not real apps. It would be very helpful to us to have examples from folks like yourself to improve our performance test suite with some real-world use cases.

    Before joining Sencha, at my previous employer, I used Ext JS 3.x heavily in complex ways and the performance problems we experienced were mostly of our own making. Not to say the problems you are describing are dismissable or anything, but rather I am curious to understand the specific problems you are describing.

    I don't know if this is one of the areas where you are having performance problems, but I feel confident that we will see some real gains in Grid. As you no doubt know, Grid in v3 was a rather complex piece of DOM. This costed in many ways (column resizing for example). In v4, Grid's DOM is much simpler: a table in most cases. And you don't have to turn off all the features to do buffered rendering as we often did in our app in v3. In 4.1, Grid now uses native scrolling as well, which helps tremendously on the user experience there.

    As we solve the performance problems around Grid, the improvements inside Grid should really stand out.

    + =
    Don
    Don Griffin
    Ext JS Development Team Lead

    Check the docs. Learn how to (properly) report a framework issue and a Sencha Cmd issue

    "Use the source, Luke!"

  8. #8
    Touch Premium Member
    Join Date
    Nov 2010
    Location
    Chicago
    Posts
    1,321
    Vote Rating
    114
    LesJ is a glorious beacon of light LesJ is a glorious beacon of light LesJ is a glorious beacon of light LesJ is a glorious beacon of light LesJ is a glorious beacon of light LesJ is a glorious beacon of light

      0  

    Default


    See what the Dojo team did to improve IE performance:

    http://shaneosullivan.wordpress.com/2010/08/28/dojo-gets-a-speed-boost-on-ie6-and-ie7/

    T
    he comments about DynaTrace and className touching might be useful.

  9. #9
    Sencha Premium Member skirtle's Avatar
    Join Date
    Oct 2010
    Location
    UK
    Posts
    3,592
    Vote Rating
    323
    skirtle has a brilliant future skirtle has a brilliant future skirtle has a brilliant future skirtle has a brilliant future skirtle has a brilliant future skirtle has a brilliant future skirtle has a brilliant future skirtle has a brilliant future skirtle has a brilliant future skirtle has a brilliant future skirtle has a brilliant future

      0  

    Default


    Interesting article. From comparing the removeCls methods in 4.0.7 to 4.1-pr1 it looks like className touching is one of the improvements being targeted.

  10. #10
    Sencha - Ext JS Dev Team dongryphon's Avatar
    Join Date
    Jul 2009
    Posts
    1,344
    Vote Rating
    134
    dongryphon is a name known to all dongryphon is a name known to all dongryphon is a name known to all dongryphon is a name known to all dongryphon is a name known to all dongryphon is a name known to all

      0  

    Default


    Quote Originally Posted by LesJ View Post
    See what the Dojo team did to improve IE performance:

    http://shaneosullivan.wordpress.com/...n-ie6-and-ie7/

    The comments about DynaTrace and className touching might be useful.
    Interesting article. Our add/removeCls methods do check for non-change and generate one write to className. We have already considered a combo method that can add and remove in a single step, but it would only be rarely useful internally.
    Don Griffin
    Ext JS Development Team Lead

    Check the docs. Learn how to (properly) report a framework issue and a Sencha Cmd issue

    "Use the source, Luke!"