Page 3 of 4 FirstFirst 1234 LastLast
Results 21 to 30 of 34

Thread: EXT JS 6 performance

  1. #21
    Sencha - Ext JS Dev Team nohuhu's Avatar
    Join Date
    Jun 2011
    Location
    Redwood coast
    Posts
    401
    Answers
    26

    Default

    Quote Originally Posted by suzuki1100nz View Post
    Ok so we disagree on wording - lets call the dom footprint "Heavy set" or "Chubby".
    You see, one of the problems in this discussion is that you are trying to attach emotionally loaded epithets to something that has no relation to emotion. By calling Ext JS DOM footprint "chubby" and Sencha Touch DOM footprint "lightweight" you imply that one of them is performant while the other is is not; and going further that one is "good" while another is "bad".

    This is what I have an issue with. There is no good or bad, there are tools designed to solve different problems with entirely different set of constraints. It is logical to assume that since original problems were different, the resulting tools are also different. Not good, not bad, just different. You are trying to judge one tool by another tool's categories; in my opinion this approach is counterproductive.

    To give you a palpable analogy, Ext JS is a heavy duty diesel truck. It was designed to carry heavy loads as fast and efficient as it possibly can. Complaining that a heavy truck can't race with a dune buggy is just wrong.

    I never said you or anyone at Sencha does this.
    The features Sencha add are great - I'm well aware software developers and software companies don't add features "willy nilly" driven by a need to cripple the product they are trying to sell, you missed your sarcasm tag in the above quote.

    I have a rough idea of what battles you face and in fact I have my own performance battles using Ext 5 on a tablet. Don't get me wrong I think the product is great and not many would decry the richness and features it provides and its stunning grid.
    But it could be lighter with its "Heavy set" dom, its could be faster and reign in performance losses from Ext 3 and with the Modern toolkit leveraging CSS3 and the need for a new component build what better time to have it happen.
    You were quick to notice the omitted sarcasm tag but you really missed my point there: your assumption that "heavy set" DOM is negatively affecting Ext JS performance in perceivable ways is largely emotional and is not based on any hard data. Nobody has done any benchmarking so far to prove or disprove this assumption.

    Guess what? I don't have such data either. But what I have is the experience of oh so many hours and days spent profiling the framework and trying to squeeze every bit of speed out of it. Take this with a grain of salt but so far I just fail to see any obvious direct relationship between the number of DOM nodes and perceivable Web application performance.

    Regarding performance losses from Ext 3, again you are comparing apples to oranges here. Ext 3 and Ext 5 are practically different frameworks sharing the name and bits of API. What, do you think the class system with all its complexity and flexibility that enables Ext 5 even to exist, is free? That's just one example among the many.

    It is ridiculous even to try comparing Ext 5 to Ext 3. Why don't you compare Ext 5 to, say, Dojo? Because it is far inferior in terms of feature richness. You acknowledge that the power does not come without cost, it is logical. Why don't you acknowledge the same for Ext 5 vs Ext 3?

    Also, Ext 5 is less performant than Ext 3 not because its DOM is heavier. It is less performant because the amount of JavaScript code that runs in Ext 5 app is several times more than in Ext 3 app.

    Come on - code branching overhead at run-time would be minimal, checking a few config when generating the dom elements.
    Are you sure of that? Did you do any profiling to back your claim? My experience tells me exactly the opposite: the minimal runtime overhead of code branching times the number of components becomes very non trivial. And that's the cost that you cannot easily shed. In fact it might be the case when you can't get rid of that cost at all.

    Speaking of which, this is exactly where we are at with Classic toolkit. The code is very optimized, all the hot paths were profiled and manually fine tuned to a ridiculous degree. We do such insane dirty black magic with garbage collection that the Spanish inquisition would burn the whole team at stake if we did that back in Middle ages.

    And you know what? It's still not performant enough. Because it's the death of a hundred of thousand cuts. Every tiny conditional, variable allocation, closure creation, context binding, etc, etc - it all adds up to the insane amount of JavaScript instructions that need to be executed even before your app is shown in the browser.

    Duh, laying out a few hundreds DOM elements is child's play compared to that.

    Yes you're right new code requires maintaining and testing.
    And the business cost for that is staggering. You are underestimating the amount of testing that needs to be done to ensure the framework quality. You can probably afford much less rigid QA in your apps but in the framework it's a totally another story.

    Somehow you want us to magically make the framework cheap, fast, and bug free at the same time. Eh, pick any two...

    I should be able to configure the feature rich button so that the features can be switched off with config and the related dom elements not generated.
    It would allow me to use the features Sencha provides as and when I need them rather than the dom output assuming I'm going to want them all.
    Like I said you are welcome to develop your own set of components that will be more fitting to your particular purpose. A framework is a generalistic tool, it cannot possibly be made specific for you alone. It's all about compromises you know.

    Yes I am expecting the modern toolkit we end up with will be fast, efficient and as rich as Classic, but then I have high expectations.
    What I was saying all along is that your expectations are emotionally loaded and consequently murky. "Fast, efficient and as rich as Classic" does not tell me much because you do not define either "fast" or "efficient".

    1/. Modern does not have to support legacy browsers
    This undoubtedly will give us some performance gain although the scale of it remains to be seen.

    2/. Modern leverages full CSS3 features including new layout features, not all of which will be applicable for some layouts
    CSS layouts will give us a lot of gain in terms of code loss. We will shed a ton of it and not have to maintain it anymore, yey. However if you assume that all runtime cost will suddenly go away just because it's CSS and not JavaScript, you might be in for a rude awakening #2.

    The browser still has to run the calculations and do a ton of stuff, you know. And browsers are not magical, visibly so. They totally suck at laying out tables for example. Why do you think we had to go back to Ext 3 style grid layouts with table-per-row instead of one huge table with many rows? Exactly because it was very slow. In all browsers, including modern ones.

    Ext JS layouts are very flexible and insanely complex. To the best of my knowledge nobody has ever tried to implement the same level of flexibility in CSS layouts. I sincerely hope that it will be much faster than JavaScript layouts but I'm not holding my breath for an order of magnitude faster.

    I would be extremely surprised if we ended up with a modern toolkit that did not out perform Classic.
    I would be extremely surprised too if Modern toolkit was not faster than Classic at least in some performance categories, possibly faster overall as well.

    What I'm trying to get through to you is that it is much more productive to recognize the framework as a tool and set some healthy expectations about it. If you are concerned with performance, do your homework. Create a simple test app that pinpoints the problems you have now in Classic, and port it to Modern when corresponding components are available. Then benchmark it and see if there is a gain or loss. This way you will be in the place to assess the results objectively instead of relying on emotions.

    In the end it's all about expectations vs results. For example, the biggest problem with Ext JS 4 was not its poor performance or the amount of bugs. It was usable at 4.0 even if barely. But the expectations for it were set at such insanely high level, it was so overpromised that it was absolutely guaranteed to disappoint long before it was released, and no amount of bug fixing could help that.

    And that was a very valuable lesson I think. Keep it cool, weigh pros and cons. Don't require: ['Ext.mixin.Emotional'].

    Regards,
    Alex.
    Regards,
    Alex.

  2. #22
    Sencha Premium User
    Join Date
    Apr 2011
    Location
    New Zealand
    Posts
    716
    Answers
    45

    Default

    ok Thanks for the response and there really is no emotion involved, a bit of fun maybe.

    Furthering this discussion will get us nowhere and provide little benefit.
    Thanks for your responses but lll take the following away.

    1/. I have unhealthy expectations of the framework performance
    2/. Provide hard evidence of poor performance
    3/. Slimming the dom via code branching at runtime is not an option (This I disagree with completely and I think it would improve app rendering time on the tablet significantly as well as improve animations, drag drop, resize, scrolling performance of grid and tress etc.. I understood keeping the dom light was a mantra for mobile development which should translate to desktop as well, achieving this with a bit of JS code overhead, I think would be worth it. It would be less code maintenance overhead than providing another set of lightweight widgets and it would save the community building there own lightweight versions)
    4/. The most positive statement -
    I would be extremely surprised too if Modern toolkit was not faster than Classic at least in some performance categories, possibly faster overall as well.
    Regards Troy

  3. #23
    Ext JS Premium Member
    Join Date
    May 2008
    Posts
    261
    Answers
    1

    Default

    I'll put my 1 cent opinion on ExtJS performance. In a way, ExtJS has 'failed' to promote the usage of Sencha Cmd. Even the books failed to even mention at all. The biggest complaint of ExtJS is the initial download of JS file and gazillion application ExtJS code (model/store/view/util/services/etc...) This all could've been fixed by using MVC and use 'Sencha app build prod'. I am guessing less than 2% of the ExtJS community actually use Sencha Cmd on ExtJS 4 or lesser version. This time around, I am glad to see 'Sencha Cmd' being highly visible.

    As far as having less code = better performance is 'most' likely true. The performance done by 'native' and by 'api' should usually be 'faster'. Even if it's not faster, it's just better since it'll have less code which means there's less code to test. Talking about tests... when will ExtJS come w/ their own testing packages? The MVVM is great! but seriously... no testing package for those? ExtJS have said that they have over 200,000 test cases.. Show us an example of how you recommend testing on MVVM? That would be nice.

  4. #24
    Ext JS Premium Member
    Join Date
    Sep 2008
    Location
    Raleigh, NC
    Posts
    164
    Answers
    1

    Default

    Hey on the subject of performance in "modern", are ya'll doing shadow dom + dom-diffing, ala React and EmberJS?

  5. #25
    Sencha - Ext JS Dev Team nohuhu's Avatar
    Join Date
    Jun 2011
    Location
    Redwood coast
    Posts
    401
    Answers
    26

    Default

    Quote Originally Posted by qooleot View Post
    Hey on the subject of performance in "modern", are ya'll doing shadow dom + dom-diffing, ala React and EmberJS?
    I'm not aware of any such plans at the moment but in the end, who knows.

    Regards,
    Alex.
    Regards,
    Alex.

  6. #26
    Sencha User
    Join Date
    Jul 2009
    Posts
    69
    Answers
    1

    Default

    I liked Tory's idea of conditionally generating DOM for components based on their config and used features. I believe that this will certainly reduce the DOM footprint because, one may be using many features of various components in different places, but it is very unlikely that one uses all the features of each component all the time. Assuming that these features require more DOM to apply styles and provide functionality, if certain features are not used then additional DOM can be shaved off. I am convinced with Alex that a few hundred additional DOM elements probably will not make any significant overhead as compared with what will come due to run-time conditionals, but components that are repeatedly used in the application such as a grid cell will possibly benefit significantly.

    Personally when I code, I try to avoid too many conditionals or optimize them in the first place by tweaking the conditional flow or placing more probable conditions first (which often comes with the cost of readability). One approach that I can think of in this case is to have a template generator mixin that performs caching to improve the speed. Here is how I envision it:
    • At the time of component initialization, a compound template lookup key is generated that combines the component xtype and feature names that are needed.
    • Template generator mixin can return the template string immediately if found in its cache.
    • If the template is not present in the template generator's cache, it can analyze the lookup key and goes through all the conditionals to generate the optimal template string that can be cached for consecutive lookups.
    This way the run-time conditionals will execute only once for every uniquely configured component and will behave for the rest of the repeated occurrences as if they are simple template strings. Obviously, the mixin needs to know about every component's conditional templating mechanism hence this functionality may be present in the component's class itself hence no mixing is needed to accomplish this. Irrespective of the implementation details, I believe that such a technique will reduce the generated DOM without too much run-time overhead.

  7. #27
    Ext JS Premium Member
    Join Date
    Sep 2008
    Location
    Raleigh, NC
    Posts
    164
    Answers
    1

    Default

    I agree with nohuhu that the "heavy" DOM is not the performace bottleneck that is often perpetuated. With that said, I think we're overlooking a few things:

    1) The DOM size makes styling via inspecting the existing DOM less approachable for designers. There is not much confidence that the DOM will stay the same. SASS styling was hard in Extjs, and compass is slow. Its probably much easier in Sencha Touch due to simpler components, smaller DOM, etc. We can debate this, but if it really was easy in Extjs, then Sencha would have most certainly put out several themes instead of just one per major release (neptune in 4x, then crisp in 5x).

    Lets leave this aside for now, until we evaluate fashion.

    2) DOM size also means its harder for developers to override components with x-templates to change parts of an existing widget, or use core widgets as examples to quickly build others. Its dense material, so the learning curve is much steeper than other libraries. We can also debate this, but there are certainly more small angular directives than extjs user extensions released (as a per-community-member per month kind of aggregate stat).

    My suggestion is we support ES6 template strings (sencha cmd to become more like traceur/babel to support older browsers), and work to improve Ext.dom.Element along with some automatic references in viewcontrollers if we stick certain classes in nodes in the template. I.e. make it easier to let us build our own components like custom nav elements, kanban boards, etc.

    I'd be happy to share some of my examples and show equivalents in emberjs/bootstrap+jquery+backbone/etc. - and how it takes more code and intimate knowledge of the API with extjs (meaning once again its harder for a designer to do this).

  8. #28
    Sencha User
    Join Date
    Jan 2013
    Posts
    45

    Default performance

    we use EXT JS because we believe it is most poweful java script frame work in the world and
    performance is not every thing.techferry run benchmark and ext js was heavier from other frameworks ,we hope in the next releases ext js will be lighter

  9. #29
    Sencha Premium Member
    Join Date
    Jul 2009
    Posts
    137
    Answers
    1

    Default

    Hi, Glad to read that Sencha is working on bringing Modern to feature parity with Classic. Do you have a roadmap for achieving this, or at least certain milestones along the way? It'd also be awesome to see an app starter dashboard for modern toolkit that sizes to a phone. While we're on this topic, I'd love to see Sencha do more with calendar and scheduling without having to go to Bryntum or Extensible.


    Quote Originally Posted by nohuhu View Post
    That said, our long term goal is to achieve relative feature parity between Classic and Modern toolkits. And no that does not mean that we will be dumbing Classic down to the Touch level. Quite to the contrary, we will be improving Modern to bring it to Classic level. Unfortunately Modern is so far behind now that it will take some gargantuan effort to get it where it needs to be to compete with Classic on desktop devices.

    Regards,
    Alex.

  10. #30
    Sencha Premium Member
    Join Date
    Nov 2010
    Location
    Argentina
    Posts
    31
    Answers
    1

    Default

    Hi, I need to compile a smaller app.js, only with the dependencies that my program uses. Is there any way to optimize the app.js size?Thanks

Page 3 of 4 FirstFirst 1234 LastLast

Similar Threads

  1. On performance
    By edspencer in forum Ext:Bugs
    Replies: 11
    Last Post: 11 Sep 2011, 5:16 PM
  2. Help me about performance EXT.
    By maychu123 in forum Ext 3.x: Help & Discussion
    Replies: 3
    Last Post: 23 Aug 2011, 12:46 AM
  3. performance
    By dddesign in forum Sencha Touch 1.x: Discussion
    Replies: 1
    Last Post: 6 Sep 2010, 1:44 AM
  4. GXT 2.0 Performance
    By dgildeh in forum Community Discussion
    Replies: 1
    Last Post: 2 Jun 2009, 7:25 AM
  5. bad performance ie6
    By mlarese in forum Sencha Ext JS Q&A
    Replies: 1
    Last Post: 8 Nov 2007, 6:38 AM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •