Hybrid View

  1. #1
    Sencha Premium Member skirtle's Avatar
    Join Date
    Oct 2010
    Location
    UK
    Posts
    3,604
    Vote Rating
    325
    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

      6  

    Default ExtJS: Performance Best Practices

    ExtJS: Performance Best Practices


    With the Sencha dev team hard at work improving the underlying performance of ExtJS 4 there has been a lot of talk on the forums about how to write fast applications. Those of us who've been using ExtJS for a while will all have experienced sluggish UIs and in many cases the problem lay in our applications, not the library itself.

    I thought it might be interesting to get some discussion going about what techniques people have used to improve UI performance in their own applications. It would be interesting to compare notes and possibly generate some metrics to see which 'optimizations' actually work. If there's sufficient interest perhaps it could even turn into a blog post.

  2. #2
    Sencha - Senior Forum Manager mitchellsimoens's Avatar
    Join Date
    Mar 2007
    Location
    Gainesville, FL
    Posts
    37,327
    Vote Rating
    850
    mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute

      0  

    Default


    Before Sencha Touch I didn't do too much performance optimizing to be honest... Now that I have been using Sencha Touch, performance is a top-tier concern that has been carried over to my Ext JS (3 & 4) work.
    1. Create abstracts. This cuts down on code duplication and bunch of other good things.
    2. DOM is the slowest thing ever! There is a trade-off with cute "features" and performance. If you have a TabPanel or Card layout, use deferred rendering. I go as far as to destroy cards (or remove all items) that aren't visible.
    3. Code smart... there are tons of tricks to accomplish the same thing but with more efficient code.

    These three have been at the main-stray of my development this last year and have helped a ton.
    Mitchell Simoens @SenchaMitch
    Sencha Inc, Senior Forum Manager
    ________________
    Check out my GitHub, lots of nice things for Ext JS 4 and Sencha Touch 2
    https://github.com/mitchellsimoens

    Think my support is good? Get more personalized support via a support subscription. https://www.sencha.com/store/

    Need more help with your app? Hire Sencha Services services@sencha.com

    Want to learn Sencha Touch 2? Check out Sencha Touch in Action that is in print!

    When posting code, please use BBCode's CODE tags.

  3. #3
    Sencha - Ext JS Dev Team dongryphon's Avatar
    Join Date
    Jul 2009
    Posts
    1,365
    Vote Rating
    135
    dongryphon is a splendid one to behold dongryphon is a splendid one to behold dongryphon is a splendid one to behold dongryphon is a splendid one to behold dongryphon is a splendid one to behold dongryphon is a splendid one to behold

      0  

    Default


    One of the biggest, yet distributed across the framework, costs we found in profiling 4.1 was the cost of DOM updates made in methods like afterRender or onRender. Many components made "harmless" calls like createChild('div') or addCls or removeCls in these methods.

    We made a big push to move as much of this stuff as possible into beforeRender and the renderTpl which eliminated dozens of reflows. The same should be considered for custom components, especially if those components are heavily used.

    I'm not sure how helpful this will be in general, but in 4.1 we added Ext.getDetachedBody() as an alternative to Ext.getBody(). This was to optimize cases where we had to render a component (like a drag-drop proxy) but didn't want to pay for extra reflows. The "detached body" is just a div that is not part of the document, so anything rendered into it cannot be measured, but you can still set classes, styles and event listeners. We simply move these elements to the real getBody on-demand.
    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!"

  4. #4
    Sencha Premium Member skirtle's Avatar
    Join Date
    Oct 2010
    Location
    UK
    Posts
    3,604
    Vote Rating
    325
    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 Grid Performance

    Grid Performance


    Many applications include one or more large grids with many rows and many columns. If you're having performance problems it might be worth experimenting with a much smaller grid, say 10 records and 4 columns. Whilst this obviously isn't acceptable for the finished application it can be useful to help diagnose where your performance problem lies.

    If using fewer records does improve performance then it is also worth considering whether the problem lies more generally with loading large volumes of data from your server. For large volumes of data it can take a number of seconds for a browser to parse a JSON response and create the records, before it even begins trying to render the data to the grid.

    In many cases a customer will be willing to accept a much smaller page size if it makes the UI much faster. Often the page size for a grid is just a number that was plucked out of the air and a grid that seemed quite snappy in the initial prototype may well be much slower by the time the rest of the UI has been bolted in.

  5. #5
    Sencha Premium Member skirtle's Avatar
    Join Date
    Oct 2010
    Location
    UK
    Posts
    3,604
    Vote Rating
    325
    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

      2  

    Default Less Is More

    Less Is More


    Most of the ExtJS applications I've seen suffer from panel explosion. Everything is done using a panel, or to be more accurate, everything is done using several panels.

    There are alternatives.

    The first problem is over-nesting. Panels within panels within panels, when one panel would suffice. Often people don't even realize they're doing it.

    The next problem is using a panel when there are much more lightweight alternatives. Everyone loves panels but truth be told they're overkill for most parts of a UI. I once saw a UI that displayed a few dozen thumbnail images and each image was rendered as the HTML content of a different panel. All those panel were totally unnecessary. Consider instead...
    1. Could you use HTML and CSS instead of a full component? An Ext.Template or Ext.XTemplate might prove helpful.
    2. Could you just use a custom Ext.Component? There are various config settings for injecting HTML into a component: autoEl, html, tpl & data.
    3. Could you use a DataView to render all of your data instead of a number of individual components?
    4. Could you use an Ext.container.Container rather than an Ext.panel.Panel to reduce the overhead?

    The more panels (and components in general) you create, the more stress it will put on the layout system and the larger the DOM will be.

  6. #6
    Sencha Premium Member skirtle's Avatar
    Join Date
    Oct 2010
    Location
    UK
    Posts
    3,604
    Vote Rating
    325
    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

      1  

    Default Handler Functions

    Handler Functions


    The functions used for callbacks and listeners are a common source of problems. They not only take time to create but can also form expensive closures.

    Consider this example:

    Code:
    Ext.define('MyClass', {
        ...
    
        constructor: function(config) {
            ...
    
            this.store.on('load', function() {
                ...
            }, this);
        }
    });
    The thing to realize is that a new listener function is created each time this constructor runs. This not only takes time but could potentially leak loads of memory though a closure. The preferred pattern looks like this:

    Code:
    Ext.define('MyClass', {
        ...
    
        constructor: function(config) {
            ...
    
            this.store.on('load', this.onStoreLoad, this);
        },
    
        onStoreLoad: function() {
            ...
        }
    });
    In this case the listener function is created once and stored on the class. Each instance will share the same function. The overhead for creating the function is incurred just once and there's no risk of a leaky closure. Even better, this style of coding makes it easy for subclasses to change the listener with a simple override.

    For completeness, I should point out that my use of on is probably misguided here. Though there are other factors to consider, it would usually be better to write it using mon instead:

    Code:
    this.mon(this.store, 'load', this.onStoreLoad, this);
    This will ensure that the listener is automatically removed when instances of MyClass are destroyed.

  7. #7
    Sencha User
    Join Date
    Apr 2014
    Posts
    1
    Vote Rating
    0
    manlystanley is on a distinguished road

      0  

    Default


    I'm new to EXT JS, but having done years of embedded systems development. Always, the rule of thumb for increased performance was never copy data (e.g. never move it from point to point, or reformat it in anyway). In looking over the various comments here, that seems to be the jest of many comments.

    A second group of comments seems to be don't use certain EXTJS functions over other EXTJS functions. I wonder if this just boil down to two main points:

    -- Don't reformat or move data.
    -- Don't use expensive EXTJS functions.

    Would this be a correct statement?

    Thanks, Stan