11 Sep 2012 10:33 AM #1
Planned Areas for Performance Improvements in 4.next
Hi All -
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.
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.
14 Jan 2013 4:22 AM #2
First of all, thank you for the excellent framework!
And a small question. Is there anything special in the plans to improve performance in IE? Or just improving performance on a whole which should affect IE as well?
31 Jan 2013 7:59 AM #3
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.
13 Feb 2013 2:20 PM #4
Are some of these already in 4.2 beta or not? I am interested in the Optimized Component Life Cycle and Optimized Panel layout.
11 Mar 2013 7:27 AM #5
Current state of play in terms of performance gain over the last 6 months
Tested under a very complex test app… using majority of EXTJS Features.
Average Test app load times - VS - Build - VS - Browsers
Build : 188.8.131.521 (Sept 2012)
I.E. 8 : 8.328 Seconds
Chrome : 1.438 Seconds
Build : 184.108.40.206 (Nov 2012)
I.E. 8 : 7.651 Seconds
Chrome : 1.370 Seconds
Build : 220.127.116.119 (RC) – (Mar 2013)
I.E. 8 : 6.577 Seconds
Chrome : 1.277 Seconds
Conclusion: Each version has improved Framework performance.
Overall Performance increase from 18.104.22.1681 to 22.214.171.1249 (RC)
I.E. 8 : 26.623 % Increase
Chrome : 12.608 % Increase
Well done guys. The framework is performing much better and looking through my raw timing figures, memory leaks seem to be handled now.
I.E. 8 Is still a way off Chrome's performance under the 4.x framework however... compared to 3.x
11 Mar 2013 8:06 AM #6
13 Mar 2013 12:41 AM #7
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.
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)
- 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.
- This also helped tab panels since Tab extends Button. This really helped achieve this little trick as well http://docs.sencha.com/ext-js/4-2/#!...side-tabs.html
- Simplified managed dockedItem border logic ... though this only helps complex dock layout arrangements, it turns out people have those in their apps
- Cmd now allows you to build only the SASS you need in to your apps so that can help reduce the CSS size and improve performance a bit... unless you are using most to all of the framework of course