SenchaCon 2011: ExtJS 4.1 Enhancements to Performance, Grid and API

Don Griffin, @dongryphon, from Sencha presents on ExtJS 4.1 features and performance improvements which I recently watched on vimeo here.  These are my notes from that session.

Main theme is performance, especially in the Grid.  On IE8, it takes ~4.7 seconds to fully render the Grid, with render and layout taking the most time and initalize and load taking the least. In 4.1, the load time is cut 2.4 seconds in IE8.  Focus was placed in all areas to improve on this to get it closer to the way it was in 3.4, but there are many more components in 4 which exacerbates the issue.

Regarding initialization, you can use the new class system and minimize the classes you load by using custom build.  This will then only load the classes (over the network) that you use in your app.  initComponent was also improved.

Rendering changes in 4.1 including removing createElement (createElement is fairly costly in 4.0); renderTpl manages this better by creating the elements in the hierarchy and then using renderSelectors during onRender to tie it back to the base element rather than doing this incrementally.  In 4.1, you now need to move custom code from onRender to beforeRender so that it gets called prior to be created in the DOM.

In 4.1, dockedItems config is available to add titles and other things to the edges of a container.

CSS calculations are expensive: Write + Read = Reflow because when you write to the DOM, the browser won’t cache it and thus causing an expensive reflow. In 4.1, “layout context” is moved to the global context so all the components are read at once and then writes after everything is read first. This minifies reflows and thus performance.

Other areas of investigation include converting layouts to CSS where possible, optimizing class creation and optimizing DOM Event binding.  This is being looked at for future releases.

In 4.1, Grid scrolling has gone back to “native scrolling” (or having true momentum when scrolling) especially when infinite scrolling.  This is a big deal since there were so many issues with the feel of scrolling in version 4.0; it wasn’t very smooth especially in IE.

API enhancements for 4.1 include:

  • Border Layout you can now do multiple regions (i.e., 2 west’s and 2 east’s) without nesting border layouts.  You can also set preferences to how regions layout with each others.  Regions can be added and removed dynamically too all within ONE border layout.  Splitters work as you’d expect, respecting the borders of its neighbors.
  • XTemplate compiles and runs faster and is now debuggable.  Now they compile to a function and support else, elseif and switch case control statements.  You can also add code right into the template.
  • Overrides will allow you to only bring in the components that you’re using in your build.

When porting from 4.0 to 4.1 you may need to check your custom layouts since now there is the global context for rendering as well as onRender which I mentioned earlier.

Increasing performance by 2 fold should certainly be welcome, but I especially like that attention was given to grid scrolling because I found it nearly unusable in 4.0 when using IE.  That will make my customers very happy.

For more information, I would encourage you to take a look at Ed Spencer’s blog on the subject.  An even more recent article is here that speaks to how to take advantage of the 4.1 performance enhancements in detail.


SenchaCon Day3: SenchaTouch Performance Optimization

Tommy Mainz gives this talk.

Problems: DOM size, events, drawing, animation and code execution all affect performance on mobile devices.

DOM size:

  • Smaller screens help to keep DOM size smaller because there’s only so much data you can show without cognitive overload.
  • However, destroy components that you’re not using anymore in the deactivate. E.g. container.on(‘deactivate’, function(oldCard), { oldCard.destroy(); }); container.setActiveItem(newCard, ‘slide’); or overlay.on(‘hide’, function() { overlay.destroy(); });

Events – Solutions:

  • Use Event Manager from SenchaTouch which has automatic removal of listeners and delegation for Touch events.
  • Use event delegation when possible e.g. Ext.get(‘list’).on{ tap: function(e, target) {target.toggleCls(;pressed’); } delegate: ‘.list-item’)

Drawing: GPU

  • Keep your DOM structures “light” (especially in Android) by limited amount of advanced CSS3 (e.g., opacity, rgba, border-radius, gradients, text-shadow and box-shadows) and limiting the amount and depth of DOM elements.
  • Don’t go too deep: prevent unnecessary layouts. e.g. you have a tab panel with a panel of two tabs (using layout of fit) but instead should just use tabpanel with items being tabs.

Animations: GPU

  • Slide to a list e.g. on beforeActivate use list.setload(true) on activate remove loading mask (set it to false).  It will be more seamless and less burden on the

Code Execution: Compiler

  • Android v8 compiler is leading in this space
  • Not the usual suspects, like CPUs and JS engines
  • The reason is JIT compilation which is related to size of the file that the method exists in; complexity of method doesn’t seem to be relevant but comments/docs in code
  • Solution is to use minified and compressed code of both SenchaTouch and your own code.
  • You can set up builds to do this with .jsb3 files (JSBuilder is bundled with SenchaTouch)  you have builds and packages that will minify and consolidate those files.