4.x Framework performance – Request for an Official Statement

[skirtle]

@skirtle, I have to say that I feel a bit surprised on how you respond to customer's concerns on bad performance in ExtJS 4. Is the general opinion from Sencha that we should go out and monkey-patch the framework to make it usable? Isn't it obvious that the performance problems goes way beyond what is reasonable?

@rich02818, @stahlman, I agree with everything you said.

Just in case there was any confusion, I do not work for Sencha and the views I have expressed are purely my own. They do not necessarily reflect the views of Sencha or its developers.

I agree that the performance of ExtJS 4 is not yet acceptable. If I gave you the impression that I think otherwise then I apologize. Sencha have also made it clear on a number of occasions that they see performance as the top priority for the next few releases.

Monkey-patching to solve performance issues is not the ideal solution but it's currently all we have. If you can afford to wait for Sencha to solve these issues then obviously there's no point trying to do it yourself. However, not everyone has the luxury of being able to wait and for those developers who desperately need to improve performance right now so that they can make a release it may be worth a shot at optimizing. There's no guarantees it will work, it's just something to consider. In many cases, like that of stahlman, it will prove fruitless and frustrating.

[dongryphon]

After scratching my head a bit, I think this means that you won't release a build that is worse than its predecessor. Is this correct? Does this mean that v4.1 when released will likely be 3x slower than 3.4.0 on examples such as that provided by Mr. Sparks?

Sorry for the confusion there... I couldn't quite tell what I meant by that after re-reading it

The "performance baseline" we have right now is 4.1 PR1. So it is a blocker to regress from there. This is currently based on measuring the Themes example and a few others.

Whether or not we will be able to include further improvements in 4.1 is TBD. I wish I could say which way that decision will go, but it is not mine to make.

Our current focus is stabilization, but we do have other promising things we want to do. These are much more isolated than the bulk of the work in 4.1 for rendering and layout, so we are not talking about large-scale efforts here. I will certainly post information regarding them if we do decide to scope them in to 4.1.

[lager]

@skirtle - I confused you with an Sencha employee, my bad!

I've tried to find an official date for the 4.1 release, but haven't found one? Where can I find such information?

[stahlman]

After scratching my head a bit, I think this means that you won't release a build that is worse than its predecessor. Is this correct? Does this mean that v4.1 when released will likely be 3x slower than 3.4.0 on examples such as that provided by Mr. Sparks?

@rich - To accept this would be to accept a "factor of 3" baseline shift from 3.4.0 to 4.0. Given that 4.0 was supposed to shift performance in the opposite direction, it seems unreasonable to consider 4.0 to be the "predecessor" to 4.1 in the context of the aforementioned acceptance test. With acceptance criteria applied selectively in this manner, it becomes far too easy to move the goalposts substantially in the wrong direction...

[stevil]

@rich, @don,

I'm confident that Sencha will address the performance issues. The question is, will it happen soon enough to retain developer interest?

Don, I know you're all busting your tails to get this done, and get it done right. And getting it done right should be the priority. That said, if 3.4.0 is the baseline for performance improvements, I think that we're missing the mark.

2.3 was the gold standard for performance - things took a hit in 3.0, improved along the way to 3.4, but nothing has been as fast as the 2.x line.

stevil

[MrSparks]

@Don,

Since your 3.4 timings were 3x slower than mine, I would have expected 10-12 seconds for 4.1, not 22. Just makes me wonder how we could be measuring the same things. Is the installation of Windows very old maybe or perhaps had lots of apps installed/removed? I've seen Windows get crazy in its old age... where "old age" is somewhere between 6-12 months.

My Windows installation is around 3 years old. Enterprise infrastructure, hardware and software have been my bread and butter for over a decade, so despite the 3 year life span of my OS, its fresh as a daisy. That’s not to say I haven’t spent considerable amounts of time isolating the issue. When 4.0 first dropped I spent a 2 week period going through my OS with a fine tooth comb, just to ensure that when I raised my concerns on the forum, they were correct.

Onto the 22 seconds mystery, that’s a good question but not a mystery. If you watch the CPU when EXTJS is doing its load, it’s driving the CPU hard. A CPU load of 70% or above is classed as being driven hard and at this point CPU performance profile starts curve off. Also the longer an app consumes CPU time for,the more context switching takes place, more and more OS processes backup behind what’s consuming the CPU time and the benchmark curves becomes ”far” less linier. You might argue from this that as long as an 4.x EXTJS app doesn’t take anymore than x seconds to load, then no one is likely to see this behaviour, however that’s out of the developers control and when the app gains size you will start to see the extended less linier load times. The only real solution for 4.x is to get it faster the 3.x and give devs a real usable performance window to play with.

I could see that spec as "high end" in some environments, but it was the lowest-end laptop you could get 6 months ago basically. We probably need to mine eBay for some even older machines.

That really depends on what industry you are in. The vast majority of company's are still sweating assets from pre 2008/2009 which when the world went financially pair-shaped. Until companies can afford to invest in new kit (which is probably few years away), business customers need to be treated with the above in mind.

Agreed - the relative performance of 3.4 vs 4 vs 4.1 is rather stable regardless of actual speed. Except with your mystery machine as noted above

As above, that’s just the way it is with PCs

With regards to hardware/os/sencha framework and what’s at fault. It can only be the 4.x framework which is causing the issue. Using the same browser on the same hardware, 3.4.0 vs 4.1 you see there is serious issue in 4.1

Again, thanks for all your help and input!

You are welcome, if you need any more input just shout. Again we really need to know if this is the right Framework for us. So if you can come back as soon as possible with an answer, we can take appropriate action.

Best
MrSparks

[stahlman]

I'm confident that Sencha will address the performance issues.

@stevil,
Given what we've been hearing, I would say you are an incorrigible optimist... ;-) I think it's safe to say that 2.3 performance levels are a pipe dream at this point... Also, you seem to have misunderstood Don's position on performance baseline. (Either that or I have...) If I understood his post correctly, he considers 4.1 - not 3.4.0 - to be the performance baseline; hence, my concerns about "moving goalposts"...

[dongryphon]

you seem to have misunderstood Don's position on performance baseline. (Either that or I have...) If I understood his post correctly, he considers 4.1 - not 3.4.0 - to be the performance baseline; hence, my concerns about "moving goalposts"...

Please don't confuse "baseline" with "goal".

The baseline simply serves as the point where a performance regression blocks the build process. Like a unit test failure. In a stabilization phase, the baseline is there to ensure we don't lose what we have gained in the previous optimization phases.

The "baseline" is also not necessarily the final word on "acceptance criteria" for 4.1. As I mentioned, that is TBD at this point.

[stahlman]

Please don't confuse "baseline" with "goal".

The baseline simply serves as the point where a performance regression blocks the build process. Like a unit test failure. In a stabilization phase, the baseline is there to ensure we don't lose what we have gained in the previous optimization phases.

The "baseline" is also not necessarily the final word on "acceptance criteria" for 4.1. As I mentioned, that is TBD at this point.

Understood. Thanks. However, I think there may be a bit of confusion here on the difference between a goal (realistic and attainable) and a mere wish. Does anyone at Sencha still believe that they can get back to 3.4.0 or better performance levels by continuing to make incremental improvements to 4.1 (and its successor versions)? Personally, I find this highly improbable. It seems to me that this would require more of a paradigm shift (e.g., something of a rollback). The sense I get is that Sencha agrees with my assessment, but is assiduously avoiding making such statements publicly. While I can appreciate the reluctance to make such statements, I also think it would be better for Sencha in the long-run to be honest about what it believes is realistically attainable. Simply saying something to the effect of "We're going to keep performance a priority going forward" doesn't really give developers the information they need to make informed decisions about which framework is right for them on future projects.

[tjstuart]

@rich, @don,
2.3 was the gold standard for performance - things took a hit in 3.0, improved along the way to 3.4, but nothing has been as fast as the 2.x line.

stevil

The reason I won't move beyond 2.3 (yet). 2.3 was a great release. None of the goodies in later versions have warranted a move IMO.

I do hope things improve beyond v4.