I was hoping that 4.1 would be more stable compared to 3.4. There are a lot of layout issues. I think Sencha should focus on that instead of performance.
Grid and (tab)panel layout do strange things. I now tested 4.07, 4.1 is not working in my app. Performance is not that good but will do, but get it stable please!
A stable program is better then a fast unstable program. And please throw out that MVC Loader stuff. I want all my js files loaded at once. It is really impossible to put my 3.4 in that MVC thing, my app is to big to handle it in the way the architecture of Ext 4 wants me to do.
Originally Posted by dongryphon
I've always used the Sencha examples (themes) when posting benchmarks on the forum. It seemed the best approach because everyone has access to the same code and its a constant.
Happy to profile my own app under 4.0.7 (it won't work on 4.1 pr1) and supply the trace file. Do you want both the IE and DNA trances? Unfortunately I wont be able to supply my apps code base because of IP. Where do I send the traces to?
Out of interest if the Sencha shipped examples (big and small) are consistently showing 4.x is slower than 3.x, how will having a trace of my App help? The performance problem isn't a customer specific case. Every user of 4.x is effected.
There are two very simple examples with code that have been in the forum for months and show that the performance problems with 4.x are not only the result of complex pages. Thus far Sencha has apparently not tried these simple examples...or has not posted the results even though that was asked for.
@Don please run the examples from the post below and let us know what the performance is on your machine using 4.1. Thanks.
Originally Posted by tvanzoelen
I could not agree more. Fixing bugs should be a priority. 4.1 already provides a decent speed improvement, but I'm not able to upgrade due to bugs, and it takes too much time to work around issues.
Here's one example... text rotation is broken and it's not trivial to find a workaround:
I hope I was not coming across as saying that we don't see any performance differences when we measure our examples. We are optimizing using them as a benchmarks.
What I am saying is that apps tend to be more complex than our examples. :) Their interactions and use of components is an important thing for us to understand, but without knowing how real apps use the framework, we have to use approximations (like our examples).
I am also suggesting that if we treat performance as we do other bugs (where possible and within reason) and we get some concrete use cases derived from how folks actually use the framework, we can incorporate that in to our continuous integration loop to the benefit of everyone.
Apologies for any confusion on that.
The current release of 4.1 is a Preview and I hope we were clear about its stability... or really its lack thereof. :)
We are currently focused on stabilizing 4.1.
MVC is optional as is the loader. One of the goals of 4 was to really help produce optimized builds based on class dependencies, so you should be able to get your JS built the way you describe.
The current 4.1 release is just a Preview and would (obviously) not be something to upgrade to just yet. We released it to see if we were on track with performance gains that we observed internally.
Thanks for taking a look and working with 4.1. Please report issues you are having so we can fix as many as possible for the final release.
You are correct and we are focused on the performance of our examples as we work to eliminate those general performance problems. That said, we are also keenly aware that while we may rack up wins with our examples, that does not necessarily translate into real world gains or at least those gains may vary by some amount. Which is why we released 4.1 so early in its stabilization phase.
What I was thinking would be of value is example code that illustrates how you compose and configure components in your app. If your app is very similar to our examples, then our current process should provide adequate coverage for your use of the framework. But if not, any examples you might provide would help expand that coverage.
An example of where this can be of value to our development process (and this is not a complaint :)): In 4.1 PR1, we have an unsupported layout use case: auto width derived from CSS and not from "shrink-wrap to content". It turns out that the Portal example and little else uses this particular flavor of autoWidth so we decided to ship with that as a known issue. It may well be that some apps are heavily reliant on that. Or maybe 99% of apps rely on it. Perhaps we would have gotten 10x the feedback on 4.1 PR1 had we prioritized this over other fixes.
The same can apply to use cases for which we might have or need special optimizations. We obviously want the most common use cases to be particularly well optimized, but "common" is really a statistical question.
A trace on 4.0.7 would probably not be that helpful now that we have reworked so much of the known problem areas... maybe 4.1... once it is stable enough for you to test. :)
Thanks for all your feedback and assistance... much appreciated!
Thanks for the reply.
I would love to give you access to my code but IP consideration prevent me form doing so.
Just to give an idea of how badly 4.0.7 performs under IE, my app takes 27 seconds to load and the UI is barley responsive. The same app under Chrome takes 5 seconds and the UI has acceptable response times.
My app is a bit of a mute point however, as say it’s not more technically complex than the Sencha example, it’s just much bigger.
Can we for clarities sake agree that there is a fundamental performance issue on 4.1 pr1? With that in mind can we agree that when the release build of 4.1 is made available, if that also exhibits the same performance profile as 4.1 pr1, that Sencha communicate exactly what the situation is.
1. We accept there is a serious issue here and will fix the problem and give the promised performance hike over 3.x
2. We know there is a serious issue here but that's the best we can do performance wise in the 4.x framework. (Outside of minor optimisations)
On a related diagnostic note, I have noticed when profiling the layout example that IE typically loads twice as many images as say Chrome or FF. Just speculation here but are you doing anything clever with the IO that waits on each get? i.e. something that you weren’t doing in 3.x
Fully understand that. I was in the same place at my last job. Maybe modifying one of our examples to be closer to your use would be possible, but I hear what you're saying: same but bigger. :)
Originally Posted by MrSparks