4.x Framework performance – Request for an Official Statement

[MrSparks]

Michael Mullany - Sencha Employee
we don’t know exactly how fast 4.1 is going to be, but if you pointed a gun at our heads, we would say it’s likely to still be slower than 3.x. If IE performance is all you care about, and you don’t care about the new features in 4.x and you have to make a decision *today* to go with 4.x vs. stay on 3.x, then we’d probably tell you to stay on 3.x. This might still turn out to be the incorrect recommendation, but if you want our best recommendation for *today* - October 31st 2011 - there it is.

@Sencha

I’ve just spotted the above on the 4.1 pr1 blog and it has me incredibly worried and depressed to say the least.

3.x by Sencha’s own admission performed very poorly and was unacceptable. If 4.x can’t even match the unacceptable performance of 3.x, then I’m really at a loss to see what the point of 4.x was. Quote “JavaScript Framework for Rich Apps in Every Browser” The key words being “apps” and “every browser” here. 4.x absolutely needs to be out-performing 3.x on all browsers to enable developers to produce “real-world” commercial web applications.

Regarding: “If IE performance is all you care about”. We have no choice other than to care about IE, it has a massive corporate install base and it’s not going away any time soon. Ironically, one of the reasons corporate users are sticking with Windows XP is because newer incantations of Windows have a huge footprint and perform badly on equivalent hardware.

Guys please tell me this awful news about 4.x isn’t true!

[saprot]

The whole new class system etc is really cool, but how many people will actually care if its Ext.define instead of Ext.extend, while it's three times slower?

Would't it be better if you'd just taken 3.4.0 and improve it, rather than making framework revolution?

[mmullany]

Guys,

Let me add another statement, which I'll add to my comment on the blog too. Is that we're not finished with performance optimization with the 4.1 release, we'll continue to improve performance in 4.2 and beyond, and we won't stop until we're happy - which is to say, at least as fast as 3.x.

-- michael

[stahlman]

Echoing MrSparks' concerns... I found the following post a bit troubling...

http://www.sencha.com/forum/showthread.php?152195-Overall-Performance/page2#post_665792

I may be reading too much between the lines, but I got the sense while reading Ed's post that from Sencha's perspective, 4.x is the new baseline against which small incremental performance improvements are to be measured. From my perspective, 4.0 should never have been released. I appreciate and applaud the desire to provide a cleaner, more object-oriented approach to html and the dom, but only insofar as it can be done without significantly impacting performance. Encapsulating messy dom implementation details in an OO cloak can be helpful, but not if I have to spend countless hours rewriting/optimizing what I've developed under the OO paradigm because it's simply too sluggish to be usable by the customer. In my case, I've spent so much time optimizing that I'm thinking I would have been better off time-wise (and certainly performance-wise) writing the whole thing using a more traditional DHTML approach.

On a philosophical note... I'm beginning to wonder whether the fundamental problem here is that the attempts to encapsulate do not sufficiently recognize the constraints of the underlying implementation (html/dom) being encapsulated. When I was profiling one of my views in Ext 4.0, Chrome and Firefox profilers were showing something on the order of 500 layouts being performed by the browser just to render the initial view! Chrome Speed Tracer flagged this (rightly so) as a problem, even though its rendering engine was sufficiently optimized (or perhaps it was that Ext was sufficiently optimized for Chrome's rendering engine ;-) to render the view without a lot of noticeable delay. But even if, by dint of Herculean efforts, the browser's rendering engine is able to do those ~500 layouts in a reasonable amount of time, the fact that it needs to makes me wonder whether we've taken a wrong turn somewhere... Just because something can be done, doesn't mean it should be. I can't speak for all developers, but from my perspective, I'd be willing to give up a bit of layout configurability/flexibility if it permitted the framework to do things in a manner that was more "natural" - i.e., in a way that didn't seem to be fighting the way the browser works. I'm thinking that if this approach were taken, we'd never see anywhere near 500 layouts for a single view rendering...

Incidentally, I don't know how many browser layouts are required under 4.1. I'm getting too many rendering errors with it at this point to do much performance testing.

Sincerely,
Brett Stahlman

[MrSparks]

@stahlman, excellent post.

@Sencha
With regards to other talk of 4.2, beyond and the performance will come. Realistically 4.2 is a year away for a stable release and that's far too long to wait for most dev's and certainly far too long to wait without a rock solid performance promise.

Comments of at least as fast as 3.x isn't anything to shout about. 3.x is already acknowledge (by Sencha) to be a poor performer, so why on earth would that now be the performance target for 4.x. That makes no commercial/development sense.

Surly when 4.x was in early alpha / proof of concept, someone at Sencha must have checked to see if it was an improvement over 3.x?

Whilst researching frameworks for my app, my 3.x proof of concepts showed me that 3.x didn’t quite have enough horsepower for my app, so my commitment (commercial and time investment) in EXT JS and 4.x was based on the fact that 4.x was going to be a huge performance hike over 3.x

Is the official line on 4.x now that performance won’t be any better that 3.x?

If that's the case (aside from the absolute nightmare that will cause me of finding a new framework and rewriting my app), what does the future hold for EXT JS. Will 5.x be even bigger and slower 4.x? Based on past major EXT JS framework releases, there's an obvious pattern developing. Where is the line in the sand? There has to be one Guys.

It honestly pains me to have to post these words because I know how much hard work and person effort the Sencha Devs have put into the framework.

[chinabuffet]

Great post stahlman... that pretty much sums up what we've been dealing with as well.

I managed to get a few screens in our app to partially render at least, but it involved numerous hacks to both my app code + the ext source files. For the most part it seemed to be quicker, but some areas just wouldn't render at all so that was probably factoring into it.

[dongryphon]

@MrSparks

Can you (without too much trouble) provide some examples that could help us profile/measure your use case(s) and understand more specifically where you are having performance problems? I know that it may not yet be possible for you to measure on 4.1, but even if the example works in 4.0 and not in 4.1, it would still be very helpful.

We rely a lot on our own examples, especially the combination examples, but they are not real apps. It would be very helpful to us to have examples from folks like yourself to improve our performance test suite with some real-world use cases.

Before joining Sencha, at my previous employer, I used Ext JS 3.x heavily in complex ways and the performance problems we experienced were mostly of our own making. Not to say the problems you are describing are dismissable or anything, but rather I am curious to understand the specific problems you are describing.

I don't know if this is one of the areas where you are having performance problems, but I feel confident that we will see some real gains in Grid. As you no doubt know, Grid in v3 was a rather complex piece of DOM. This costed in many ways (column resizing for example). In v4, Grid's DOM is much simpler: a table in most cases. And you don't have to turn off all the features to do buffered rendering as we often did in our app in v3. In 4.1, Grid now uses native scrolling as well, which helps tremendously on the user experience there.

As we solve the performance problems around Grid, the improvements inside Grid should really stand out.

+ =
Don

[dongryphon]

@chinabuffet,

Please do report problems you have getting your apps/pages to load in 4.1. (in another thread )

Seriously, though, we know there are some unfinished things that will block some apps/pages, but it will help us to prioritize knowing what folks are bumping into.

This applies not only to correctness issues, but performance issues as well. Any examples you can supply that show us how you are using the components and structuring your UI will help us optimize the framework based on actual usage. Not to mention, it will also help us test compatibility ... we cannot brute force our way through all possible combinations of configuration options.

[dongryphon]

@Stahlman,

In 4.0, reflows were optimized locally (at the container level), but because v4 typically had 2x the number of components/containers as v3 for a roughly equivalent configuration, this was not enough to avoid a catastrophic number of reflows.

For 4.1, eliminating reflows was a key part of our effort. The changes to layouts were specificially designed to perform the fewest number of reflows possible for all layouts being calculated. Given that some measurement is still required and some of that depends on previous calculations being written to the DOM.

In addition to layout changes, 4.1's rendering changes were also essential in reducing the number of reflows. For example, many components performed additional rendering and DOM manipulation after they had just placed their markup into the DOM. Now in 4.1, we do almost all that work as we produce the markup.

Please feel free to report any problems you are having getting your app/pages to load in 4.1. Our goal is to ensure as smooth a transition as possible from 4.0.x to 4.1 (final), so we really want to hear about any compatibility issues you are having.

[saprot]

@DonGryphon

let's use Sencha's own example: ext-4.1-pr1/examples/window/layout.html and ext-3.4.0/examples/window/layout.html, so they are the same.

Time used for clicking on "Show window" button and changing from Tab1 to Tab2, and from Tab2 to Tab3 (measured by Firefox with Firebug Profile button):
Ext 3.4.0: (183.555ms, 11683 calls)
Ext 4.1.PR1: (328.84ms, 32406 call)

And please don't respond like 'post your computer configuration'. Ext 4.1 is still a lot slower than 3.4.0