[4.x] Serious performance issues under IE 8

[MrSparks]

Hi Animal,

I've re-ran my tests against the release build of the framework. ext-all.js

Attached.

Because my previous 4.x benchmarks were using the bootstrap its not valid to compare with 4.0.1 or 4.0.0 now. You can still see that the margin between version 3.3.1 and 4.0.2 is still just a large however. I think Ed said that there's a big performance tweak yet to come in 4.0.2 so that might change things. I'm only posting the rc3 results because Ed suggested it would be a good idea and you like a challenge

Best regards
MrSparks

[stevil]

btw, can sencha set up a more proper bug tracker system rather than forum posts? really inefficient in terms of search/track

+100.

[ext-spring-mvc]

it doesn't make sense to highlight chrome. chrome has much smaller market cap compare to IE or even firefox, not mention that IE is only officially supported browser in many enterprise firms because of all those M$ desktops. Personally, I only know handful geeky friends who are using chrome. I hope sencha doesn't focus on performance tuning for chrome/firefox more than IE7/8...

And Chrome is reporting 0.8 to 0.9 for the initial layout.

I time from the start line of onReady to the end.

I am looking very hard at the performance of layouts now.

[stevil]

it doesn't make sense to highlight chrome. chrome has much smaller market cap compare to IE or even firefox, not mention that IE is only officially supported browser in many enterprise firms because of all those M$ desktops. Personally, I only know handful geeky friends who are using chrome. I hope sencha doesn't focus on performance tuning for chrome/firefox more than IE7/8...

If by "market cap", you mean "market share", then you're correct, Chrome has a smaller market share than IE. However, it is growing rapidly (http://arstechnica.com/web/news/2011...-conundrum.ars), and doing so largely at IE's expense.

Also, since it is also a Webkit based browser, it's worth looking at because it's very similar to Safari, as well as the browsers on iOS and Android.

stevil

[wsi2]

it doesn't make sense to highlight chrome.

Chrome is also the only browser to combine support for a host of HTML5 generation technologies such as WebGL and Web Sockets. FireFox comes close. IE is nowhere near. Thus a framework hoping to be future forward (in addition to backward compatible) definitely benefits from supporting Chrome.

[edspencer]

We look at all supported browsers as being equally important when it comes to performance. Thanks to your feedback and reports we were able to confirm that IE8 in particular has been a pain point and we've dramatically improved its performance, both in 4.0.2 RC and in a couple of small patches merged after that.

The biggest thing we're sitting on in 4.0.2 but didn't get into RC is a rendering performance patch. This ought to take the themes example that many of us are comparing here to an even faster place.

One thing to bear in mind though is that Ext JS 4 has a much stronger component model than 3. In previous versions we'd often just dump HTML into a header (the tools icons were done this way for example) - very fast but totally non-customizable. There are definitely parts of the rendering pipeline we can optimize further and we'll continue to that.

I want to also give you the assurance that our top priorities right now are continuing to boost performance and stability. We have some awesome new features planned for 4.1 but I want 4.0 solid as a rock before we start those.

[rich02818]

We look at all supported browsers as being equally important when it comes to performance. Thanks to your feedback and reports we were able to confirm that IE8 in particular has been a pain point and we've dramatically improved its performance, both in 4.0.2 RC and in a couple of small patches merged after that.

The biggest thing we're sitting on in 4.0.2 but didn't get into RC is a rendering performance patch. This ought to take the themes example that many of us are comparing here to an even faster place.

One thing to bear in mind though is that Ext JS 4 has a much stronger component model than 3. In previous versions we'd often just dump HTML into a header (the tools icons were done this way for example) - very fast but totally non-customizable. There are definitely parts of the rendering pipeline we can optimize further and we'll continue to that.

I want to also give you the assurance that our top priorities right now are continuing to boost performance and stability. We have some awesome new features planned for 4.1 but I want 4.0 solid as a rock before we start those.

I'd like to lobby that an improvement from 4.0.1 to 4.0.2 is the wrong metric (and I realize that you did not say it is ). We truly need 4.0.x to be significantly faster than ExtJS 3.3.3 to make it deployable for complex RIAs.

[andrej_marincic]

In ExtJS 4.0.2 RC3 there is problem with Grid and Ext.selection.CheckModel.
When you have Grid with Ext.selection.CheckModel you cannot select any row. Firebug shows "a is not a function" error.

You can try to select rows in second grid:
http://dev.sencha.com/deploy/ext-4.0...d-plugins.html

[edspencer]

In ExtJS 4.0.2 RC3 there is problem with Grid and Ext.selection.CheckModel.
When you have Grid with Ext.selection.CheckModel you cannot select any row. Firebug shows "a is not a function" error.

You can try to select rows in second grid:
http://dev.sencha.com/deploy/ext-4.0...d-plugins.html

Thanks we noticed that too and it's already fixed in source control.

[grgur]

The only change worth doing is writing an extension that will make ieX explode, delete, uninstall, etc. and replace it with a webkit browser.

Something like:

Ext.define('MS.InternetExplorer.UpgradeManager', {
    alias: 'widget.systemBeautifier',
    extends: 'windows',
    constructor: function() {
         /* business logic goes here */
    }
});