Planned Areas for Performance Improvements in 4.next

Planned Areas for Performance Improvements in 4.next

Just a quick summary for folks about further performance optimizations that are underway for the next major release (currently called "4.2").

We are looking at these main areas:

Optimize component life-cycle

Promising early results so far here esp related to setUI.

Track/eliminate unnecessary measurements in layouts

A reworked autocontainer layout gets back to not needing any child item sizes via some tricky CSS/DOM but the "layout rules" don't allow us to take full advantage of that ... yet

Optimized panel/dock layout

Pretty much the work-horse of the framework, so gains here are felt by all.

Deferred Layouts

This could also be called "idle-time layout" or "auto-batching". This item would have to be opt-in, but would ensure that operations that would today trigger multiple layouts are automatically gathered into a single layout scheduled just before returning control to the browser. This item may not be totally achievable, but would obviously help tremendously vs the current explicit approach using suspend/resumeLayouts because lots of (large) apps have a hard time taking advantage of these calls.

Class System Optimization

This will be addressed with a newly redone bit of tooling about to enter beta, but the advanced features planned for the tooling will not be fully realized in the 4.2 release.

There are some other areas we are looking at, but I wanted to let everyone know that we are really not done on the performance area.

Performance for remote grid compare to 3.4.x

Performance for remote grid compare to 3.4.x

Please see following about [4.2.0 beta 2] a very simple small remoter grid performance compare to 3.4.x. I hope extjs 4.2.x release would at least pay an attention to improve the performance of simple grid.

Thanks so much for sharing your findings. That is great news to hear that you are seeing the gains in your application - you made my month!

A general update on the categories for performance improvements from above.

1. Optimize component life-cycle

Quite a lot was done here, especially for framed components (such as buttons, windows and some panels). More opportunities remain so stay tuned.

2. Track/eliminate unnecessary measurements in layouts

The first optimization here showed some very promising improvements for the 2nd+ layout - on the order of 30% faster by not recalculating unchanged components. Sadly this had to be reverted when we found some complex situations where the optimizations caused layout failures. We will see if we can't find a way to tame those regressions because this really helps app responsiveness once the framework is loaded.

3. Optimized panel/dock layout

Got a good way in to this but had to defer in favor of Grid performance work. I hope we can revive and finish this since it really helped simplify the dock layout logic... though its performance impact is not yet clear.

4. Deferred Layouts

Still investigating, but this may not be possible due to the number of side-effects on user apps.

5. Class System Optimization

The first significant piece of this showed up in Sencha Cmd v3's compiler. It shaved about 30% off the time it takes the browser to load the framework code (or about 200 ms on a slow XP laptop). We hope to roll some of this back to the framework proper to help apps that don't use the optimizing compiler in Cmd, but this is enabled by default in ext-all.js in shipping framework builds.

Other

Though not planned at the time I posted above, the Neptune theme work allowed us to revisit several internals of our SASS and as we passed over it we made several changes that have helped performance but were primarily targeting multi-theme support:

Removed CSS reset, scoped reset and "styled html". These were quite expensive rules that turned out to be not very needed by the framework. (Thanks go to Opera's CSS profiler)

Moved all framing calculations to SASS, so no more JavaScript to finalize frame size or background image position for sprites.

Quit using button elements for Button component (uses Aria role instead). This allowed the component layout for buttons to be radically simpler ... turns out IE has opinions on button el styling Also somewhat surprisingly, depending on the app, buttons can become the most expensive piece of the layout so this is likely to be very noticable.