4.x Framework performance – Request for an Official Statement

[_matias_]

The following is not meant to argue with anyone as there are many use cases and what is true for one doesn't have to be for one's neighbour.

I am the first to about Ext's release strategy and lack of clarity regarding release dates. This being said, I love the way Ext is going and how it allows to write eminently re-usable and maintainable code, something that, in my use case, far outweighs having to wait. That is, provided a functional release ever sees the light in the next few months.

[nomack84]

It's true @_matias_.
I'm unhappy with Ext ATM because they release a version with many problems: performance, bugs, etc. tut at the same time, I'm not using Ext 3.4 for my projects.
It's true that ATM I'm not supporting IE, is possible to me to restrict my users, temporally, to FF and Chrome, but, Ext 4 has so many nice features, that I can't switch back to a previous version...

What is sad is they late to many time from release to release. I don't understand why they release Ext4.1-PR1 full of bugs, but is not possible to release a PR2, which certainly will have less bugs. I know they like to jump straight to Beta, but...is a long wait, and people get mad during the process.

[stever]

I don't understand why they release Ext4.1-PR1 full of bugs, but is not possible to release a PR2, which certainly will have less bugs.

I don't know about that. Different bugs, sure. But certainly not "certainly will have less bugs". Big software projects rarely work that way.

[brianpolk]

Still checking just about every day to see if a pr2 or beta is available, or if maybe just a new message has been tossed over the wall. I am a veteran software developer and an enthusiastic user of the extjs framework. Like many others, my organization has staked a lot on extjs4. We've done a lot of development, and porting of existing projects, but they have now been on hold for way too long. When asked for progress estimates, the stakeholders expect something more than crickets. Please help me to defend the decision to take this road. A pr2 would take a lot of pressure off at this point. We know you are all working very hard on this, and are dedicated to a quality deliverable. Please keep us better informed of what to expect over the coming week(s), month(s) or if it might be longer than that, we just need to know.

[nomack84]

There won't be a pr2, they'll switch to beta1 directly, and it should be ready before the end of this year, so be patient....

[nbourdeau]

Any update on performance issues with Ext4 ??
Espescially with IE ?

[Grolubao]

The unfortunate truth is that Sencha is aiming their efforts in Sencha Touch and not ExtJS. All the tweetings, etc, is towards Sencha Touch.

It's incomprehensible that it takes so many months to iron out the bugs. It's also not possible that these performance problems couldn't be measured before releasing ExtJS 4.

There is something very wrong going on, and I'm really afraid that the latest stable version from Ext would be 3.4

[mmullany]

We have had a full team working on Ext JS since we shipped Ext JS 4. We *just launched* Sencha Touch 2, so our marketing efforts have been concentrated on getting it into market. We've blogged along our way about Ext JS 4.1 and had a number of newsletter articles on what's going on. Ext JS 4.1 has a full rewrite of the layout system for improved performance - which is a core component that the entire framework has massive and subtle dependencies on. We're almost there.

[nbourdeau]

While my profiling did show a lot of GC, I don't know when that occurs. It could easily have been once rendering is finished and there's nothing else going on. That's my understanding of how GC is supposed to work...

I don't think the bulk rendering accounts for all the extra stuff in the heap dump. I added the following code to MrSparks's example:

var Tracker = function() {
    Tracker.count++;
};

Tracker.count = 0;

(function() {
    var join = Array.prototype.join;

    Array.prototype.join = function() {
        if (!this.tracker) {
            this.tracker = new Tracker();
        }

        return join.apply(this, arguments);
    };
})();

I also added similar code into XTemplate.applyOut.

What this does is tag each array used for a join operation with a Tracker class. I can then see those trackers in the heap dump and trace their GC roots.

Thousands of arrays were augmented (it keeps count) but only about 12 trackers made it through to the heap dump. I think all were caught in closures rather than deliberately kept and whilst this does indicate a memory leak it was only 12 relatively small arrays. The biggest culprit was the cache in Ext.DomQuery.select, which captures the array fn in the line:

eval(fn.join(""));

I then turned my attention to the strings. Some of the largest strings were HTML fragments, so I thought I might be on to something there. Turned out they were html properties on XTemplates. I made a small tweak to XTemplate so that it wiped the html property after it was compiled. While this did make those strings disappear from my heap dump it really made very little difference in the grand scheme of things.

One other observation I made is that grids keep recreating the same XTemplate over and over again. The compile times add up. It probably isn't significant compared to some of the other optimizations you're making but I managed to save myself about 5% on grid resize times by adding in a crude cache.

Hi skirtle!

Could you post these tweaks for us to test it ? Or is it already in 4.1 GA ?

Regards

[nbourdeau]

I've heard a lot of people say this but personally I've never found this to be true. While I understand that there's only so much you can do to overcome a fundamental architectural performance problem, I tend to find that I can squeeze a load more performance out of my apps just by targeting my own use case.

As you noted, out-of-the-box components need to support older browsers and all sorts of wildly varying configurations. In practice, your app may well only need to support a subset of browsers and the configuration of each component is known exactly. This gives you a major advantage in applying optimizations that might be much more difficult to attempt in the more general case.

Just like any other application, once in a while you have to break out a profiler and do some work to speed things up. This includes monkey-patching Ext the same way you would for any other bug.



Many developers aren't suffering performance problems and you can no doubt imagine their response to losing the features they were using.

While the performance of ExtJS 4 is currently slower than ExtJS 3 in all browsers, I think most of the headaches surround older browsers. While it may not be universally the case, I suspect most developers would be able to tolerate the current performance were they not trying to support older versions of IE. Trying to improve performance by ignoring older browsers doesn't really address the majority need.

Skirtle, I blog post or new forum thread about how to tweak ExtJs the way you talk for fitting our needs would be great. I do not really know where to start and/or possible spots where I could strip things to optimize a bit !
For example, If I don't want ot support IE6, is there some compatibility I can remove somewhere that will speed up things ?