View Full Version : Overall Performance

25 Oct 2011, 5:47 AM
The overall performance impact of 4.1 is not as good as I hoped for.

Here's an example from an app of ours. Doubleclicking a grid row opens a new Ext.window.Window with a four-tab tabpanel with a few grids:

With ExtJS 4.02b that takes about 1760 ms:


ExtJS 4.0.7 brings it down to about 1060 ms:


With ExtJS 4.1 it's still about 863 ms:


In all cases the provided ext-all.js was used. The values varied by about 50 ms per individual test.

25 Oct 2011, 2:03 PM
Was Ext.window.Window already loaded when you created it?

25 Oct 2011, 2:08 PM
Yes, actually I did the same doubleclick several times before (even with timeline recording enabled) to ensure that Chrome has everything cached.

26 Oct 2011, 5:05 AM
I don't know, a ~20% improvement is not to be sneezed at in my book.
A floating window with 4 tab panels and "a few" grids is a fairly complex layout, so a 800ms rendering time sounds pretty good to me.

26 Oct 2011, 7:18 AM
Can you post an example that mimics what you are doing? Ideally just an html file with script block that presents a button to display the window. Also, it would be important to accurately match where you are auto sizing in your real app because auto sizing entails extra measurements and potentially reflows.

27 Oct 2011, 3:24 AM
@Sebastien - I think you're missing the point here: keep in mind that for many developers, the performance of 4.0 was completely unacceptable - not even close to usable on certain platforms - thus, it should not be taken as the baseline for comparison... While in the abstract, a 20% improvement sounds good, if the thing being improved needs an order of magnitude improvement, 20% seems almost insignificant...

27 Oct 2011, 4:43 AM
Maybe Andre should make its expectations a little clearer then. What's *good*?

I skipped Ext JS 3 altogether so I have no point of comparison between 3.x and 4.0.
However, I've been working with Ext JS 2.0 for years and 4.0 since the first PR, and I never ran into any situation that makes an application usable. As far as my needs go, a 20% boost is a welcome improvement.
Granted, IE7/8 are not in my target browsers.

Did the affected applications you mention really performed so much better with Ext JS 3.x?
The kind of composition AndreKR describes in the OP sound a bit over the top to me. I'm not sure a window with tabs and several grids would perform that well even on a native widget toolkit :P

I don't mean to be confrontational or too supportive of Sencha, but I sometime wonder if people just don't demand way too much from Ext JS, which with all its qualities, is still *just* a fancy Javascript/DOM toolkit.

EDIT: ok, if that benchmark is to be taken seriously, there *does* seem to be quite a performance gap between Ext JS 3 and 4: http://www.sencha.com/forum/showthread.php?152386-IE-Performance-Browser-Benchmarks

I (http://www.sencha.com/forum/showthread.php?152386-IE-Performance-Browser-Benchmarks) begin to understand where all the embarassment comes from.

27 Oct 2011, 5:54 AM
@stahlman That was exactly what I meant, thanks for typing it for me. ;)

I put together a testcase by removing everything that requires data access while maintaining the layout complexity where possible. It's not exactly a single html file, but I got it down to 3 js-files for the different window types.

Here it is:

Just doubleclick lines to open additional windows. You will see that opening the window and even switching between tabs is quite slow.

27 Oct 2011, 6:03 AM
I get 350ms average to open the tabs window and ~200ms when switching tabs, using Chromium 15.
My machine is hardly a beast, how come I get such lower timings than you do?

27 Oct 2011, 8:18 AM
Hm, interesting. I can't explain.

According to Chrome's timeline, switching between tabs consumes about 280 ms, mainly for painting.

For the tests I used Chrome 15.0.874.106 on an "AMD Athlon 64 X2 4000+ 2.10 GHz".

27 Oct 2011, 11:16 PM
Well, I use a faster CPU (C2D E7500 @ 2.93GHz) but that doesn't explain the 2x difference in timing for opening the window. Maybe there are other factors at play (GPU acceleration?)

27 Oct 2011, 11:54 PM

Thanks for posting the example... I am downloading it now.

28 Oct 2011, 12:13 AM

It would probably help (on old IE's esp) to alert out the relevant times... or for dynaTrace testing to make sure the methods we should profile are named methods.

I will play with my downloaded copy to see what I can see about performance.

Thanks again!

28 Oct 2011, 2:34 PM
I see numbers like 180ms for Chrome but 880ms for IE8. I will dig further and see if I can identify the root of the problem. If you don't need splitters or collapsibility you could use table layout to avoid all the nested box layouts. It should help some.

29 Oct 2011, 6:21 PM
Thanks for the feedback so far guys, keep it coming. 4.1 is not the final word in performance, we will continue to treat it as a top priority in 4.2 and beyond.

4 Jan 2012, 7:03 AM
It got slower again in 4.1 beta 1. Now about 1000 ms for the above example. Anyway, I made an updated test case: