[4.x] Serious performance issues under IE 8

[jchau]

4.2 been out. Are people seeing better performance with 4.2? For me, it's about as slow as before.

[tprodigy1]

To me, 4.2 still doesn't perform well at all under IE8, especially tab panel rendering time and tab switching, also nested panels rendering is still way slower than extjs 3.4. the only componend which work well is the grid panel.

4.2 is still unusable for big applications in IE8
(performance seem ok in other browsers, at least on my core i7-2600 CPU)

[schmoboy]

I sure hope this eventually gets addressed. After spending months upgrading our app from 3.x to 4.x our customers (95% are stuck on IE8) have nothing but bad things to say about the degradation of performance of our "new version". For example, grid with ~20 columns each with a filter (grid filter feature). Remote paging with only 50 rows per page, so not big number of rendered rows. Grid header menus take 5 seconds to appear after clicking the header menu arrow. When moving the mouse over the menu items there is a two second pause before focus switches to the next menu item.

Switching to "Compatibility Mode" help a little, but why should that be needed?

I just can't understand how something like this that has been reported for so long goes unaddressed. I could care less about BufferedRenderer. It's not the number of rows that is causing the issue otherwise we wouldn't be seeing it with just 50 rows per page.

At this point our 4.x subscription has been a disappointment. Months of upgrade work will be thrown out as we revert back to our 3.x codeline.

[jchau]

Make good use of Ext.suspendLayouts and Ext.resumeLayouts and it should be much quicker. Wont be as fast as 3.x but your reported times are really bad...

[dougbieber]

Haven't upgraded EXTJS for 3 releases. We are on 4.1.2. 4.1.3 had a serious bug relative to dynamically building accordions which made it unusable for us. 4.2.0 had a bug in IE 8 where EXTJS was making http requests under our https app which caused an ugly IE dialog to popup every page refresh. And 4.2.1 had a lot of issues for us that were working perfectly on our current 4.1.2 release.

One thing I can say about 4.2.1 is that the grids and trees are noticeably faster under IE 8. I would strongly agree with the prior post that the suspendLayout call makes a huge performance difference in some cases.

[rich02818]

Make good use of Ext.suspendLayouts and Ext.resumeLayouts and it should be much quicker. Wont be as fast as 3.x but your reported times are really bad...

...and 3.x was considered too slow with IE8. Ver 4 was promised to resolve that and be faster...

[schmoboy]

Thanks for the suspendLayouts suggestion, but our main pain point seems to be with showing grid header menus and their associated filters. Don't think I can utilize that in this case. I looked at the code for ListMenu and I see it is using suspendLayouts at the appropriate points. I wish I could get a better handle on why exactly when I try to drop the grid header menu down that it is taking so long, but I have been unsuccessful there.

The grid itself displays reasonably fine, but the header menu performance is just unbearable. Compatibility Mode makes it somewhat better which I guess offers a clue.

[Animal]

If it is very specifically showing a menu that is slow then theres something very strange going on. I can't see how showing a menu could cause anything bad. It has to lay out the menu, but while slower on IE, laying out one menu should not be noticeable.

There must be some events firing which fire off into some other complex stuff.

Can you show a test case? Does it happen in the example page at examples/grid-filtering/grid-filter-local.html ?

Best thing would be to run Chrome's profiler during the click of the header menu trigger so that we can see the call stack and the time taken in each level.

Once we see where the time is going it should be easy to fix.