11 May 2012 1:14 PM #121
@Skirtle & @nbourdeau
I would also be very interested in the performance tweaks your mentioned and if it possible to strip out parts of the framework that would not be required on my target platforms. i.e. remove I.E. 6 (that's a dead browser these days to be honest, MS don't release security patches any more so most corporates have moved on) also how to remove SASS, MVC and a few other items that would't be needed in a performance (targeted) framework environment.
Really don't want to have to go the EXT 2.x route, just to get performance
12 May 2012 3:19 PM #122
To start with have a read of the following:
Generally I just start by using a profiler or adding some timing logging and narrowing down the cause of the problems from there. Since 4.1 came out I haven't needed to do any library tweaking, just writing application code to follow best practices has proved sufficient to get fast performance. 4.1 is still a bit slower than 3.4 but we're talking such small differences that users can't really feel it. Absolute performance is what matters, not comparisons to 3.4. Those kinds of comparisons just help to set expectations on what the ExtJS dev team should be aiming for.
@MrSparks. I'd be curious to know what sort of performance problems you're still seeing against 4.1. The example you provided comparing 3.4 and 4.0 many months ago was very useful for performance analysis but it didn't really give any hints about what sort of problems you're having in practice. Creating and rendering so many components up front the way that example did is great for finding library performance bottlenecks but in a real app you'd just do everything lazily and the load time would plummet.
If you want to strip down the JS section of the library then follow the guide to creating a custom build. You just need to create a jsb3 and then build it. You won't be able to remove dynamic loading but things like charting, MVC and Ext Direct should drop out, unless you're using them. Stripping back the CSS can also help a little. The default HTML styling at the end of the CSS is totally unnecessary unless you're using styleHtmlContent and the rules it uses are really slow. It'll only make a couple of percentage points of difference at best but if you're looking to squeeze out every morsel it's certainly something I'd do.
I've helped quite a few people upgrade from 4.0.7 to 4.1.0. In all cases we finished the upgrade in a few hours (backwards-compatibility is pretty good in my experience) and the remaining performance problems were all tracked down to inefficient application code. There are still some problem areas in the library, such as grids with many columns, but unless you're unfortunate enough to fall into one of those nightmare scenarios you should find performance is pretty reasonable.
14 May 2012 5:08 AM #123
@skirtle: The performance requirement is to be at least as fast as 3.4 in real application use. Your statement that "the remaining performance problems were all tracked down to inefficient application code" is effectively a new, subjective performance requirement that is based only upon comparisons to 4.0.x performance.
Is Sencha still committed to correcting the performance deficiencies of ExtJS 4.x and making it at least as fast as 3.4? When can we expect to see this achieved?
14 May 2012 6:44 AM #124
EXTJSIV-3283 was opened about 11 months ago, documenting 4.x performance problems with multiple tab panels. What is the current status of this bug?
14 May 2012 6:54 AM #125
Sencha's requirement: make ExtJS 4 as fast as ExtJS 3.4.
My requirement: make my customers' apps fast enough for their needs.
I would hope for the sake of your users that your own requirement is similar to mine.