PDA

View Full Version : Ext JS 4.1.3 performance vs 3.4



Tim Ward
29 Jul 2014, 4:19 AM
We have an application which we've just tried to convert from 3.4 to 4.1.3.

The performance is very poor, many times slower than 3.4 for some operations, and the result is unusable.

Where do we start trying to do something about this?

skirtle
29 Jul 2014, 8:23 AM
1. Read this:

http://www.sencha.com/forum/showthread.php?153565

2. Use built-in browser profiling tools to get a sense for where the problem is.

3. Run your page through the ExtJS page analyzer to help better understand layout problems.

Tim Ward
30 Jul 2014, 12:03 AM
(1) I'd already read it. It seems to be mostly about designing new code from scratch - I don't see anything explicit about changes between 3.4 and 4.1.3 that require corresponding application changes, or what the corresponding application changes should be.

(2) I've done some of that (and will do some more). So far it tells me that all the time goes in Ext JS code, not in application code. As a particular example, simply changing the string "1" to the string "2" via setText involves a doLayout which takes 200ms which, when two of them happen, is far too long for the poor user to wait for feedback for a mouse click - in real life of course there is no layout change so no need to waste time on such calculations.

(3) I'm considering that, I'm just concerned that it might be difficult / impossible with our multi-iframe application with a load of cross-site request forgery and other security features.

skirtle
30 Jul 2014, 12:39 AM
(1) I'd already read it. It seems to be mostly about designing new code from scratch - I don't see anything explicit about changes between 3.4 and 4.1.3 that require corresponding application changes, or what the corresponding application changes should be.

It's about making apps written in ExtJS 4.1+ faster. It doesn't matter whether you're writing from scratch or upgrading, the same rules apply.


(2) I've done some of that (and will do some more). So far it tells me that all the time goes in Ext JS code, not in application code. As a particular example, simply changing the string "1" to the string "2" via setText involves a doLayout which takes 200ms which, when two of them happen, is far too long for the poor user to wait for feedback for a mouse click - in real life of course there is no layout change so no need to waste time on such calculations.

doLayout, a mainstay of ExtJS 3 development, is pretty much dead in 4.1+. If you're calling it explicitly anywhere I'd suggested removing it. The problem is almost always excessive layouts in ExtJS 4.

The single most important performance trick in ExtJS 4.1+ is suspending layouts. It's discussed on that other thread but to be clear the pattern looks like this:


Ext.suspendLayouts();

// do stuff that causes multiple layouts

Ext.resumeLayouts(true);

This will batch multiple layouts into a single layout.

As for speeding up a single layout run, that's quite complicated and the page analyzer can help to identify what exactly is going on. The further up the container hierarchy the layout has to go to work things out the longer it'll take. Generally the more hints you give it the faster it'll be. e.g. Specifying a fixed width or height is faster because it doesn't depend on any other component.

Tim Ward
30 Jul 2014, 12:53 AM
Yes, I'd discovered that it went vastly faster with a fixed height.

Trouble is that a hard-coded explicit height needs to be calculated (or determined by experiment) separately for each font / language / browser? / whatever combination and we'd then need to manage distribution and selection of these different numbers, which all sounds rather painful to me, just to display a number in a toolbar.

But changing a displayed number doesn't make any different to the height[#] so what I may be after is some way of saying "yes, calculate the height the first time you display this widget, but don't bother to recalculate it each time I change the text because I promise that my changes to the text won't change the overall height of the widget".


[#] Assuming you're not using a font with non-ranging digits, and I don't recall seeing one of those for yonks.

skirtle
30 Jul 2014, 1:12 AM
It may not be necessary to set the height on the item itself. It may be sufficient to set some fixed sizes elsewhere, just to stop the layout ballooning out of control. I'm having to speculate wildly in the absence of any code. It's a while since I've used 4.1.3 but I don't recall putting some text in a toolbar being a major performance problem.

However, on the specific example you've given, I would expect text in a toolbar to be shorter than the other components (usually buttons) in that toolbar. So can't you just set a fixed and suitably large line-height (if there isn't one already), thus guaranteeing the total height across all platforms?

That's still a bodge though, the bigger question is what's causing the performance drain in the first place. ExtJS 4.1 had performance problems but just putting some text in a toolbar shouldn't be enough to fell it.

Tim Ward
30 Jul 2014, 1:12 AM
It's about making apps written in ExtJS 4.1+ faster. It doesn't matter whether you're writing from scratch or upgrading, the same rules apply.
I've seen various threads starting out saying "why is 4.x slower than 3.x" but none of the ones I found had any answers. What I was hoping to find was something saying "if your application is lots slower in 4.x than 3.x here are some specific things you should look for" and I haven't found any such.

doLayout, a mainstay of ExtJS 3 development, is pretty much dead in 4.1+. If you're calling it explicitly anywhere I'd suggested removing it. The problem is almost always excessive layouts in ExtJS 4.
The call to doLayout that I've identified so far as being a problem is in Ext JS code, not application code. There appear to be exactly no calls to doLayout in the entire application code base.

Tim Ward
31 Jul 2014, 3:42 AM
I've done some reworking, and made sure the text in question is the text of a Ext.toolbar.TextItem, which is present in an Ext.toolbar.Paging-derived class. Calling update() on this TextItem, giving it a new text string with exactly the same metrics as the old one, takes 400ms, of which approx 100% is in the updateLayout() call that update() makes. So this version of the question is: What, instead of update(), can I do that will go many times faster?

skirtle
31 Jul 2014, 6:05 AM
Let's try something concrete. What times do you see logged out in this example?

8a1

Running in Chrome I initially see times in the 30-50ms range but after a few clicks it speeds up to about 20ms. With a fixed size it's more like 1-2ms but let's assume that isn't an option for now.

It's running 4.1.1 because Fiddle doesn't have 4.1.3. I get similar times for 4.2.1.

If you're not seeing super slow times in my example, could you put together your own example that shows the problem you're seeing?