Thank you for reporting this bug. We will make it our priority to review this report.
Just loaded the themes example into IE9 across my LAN in about 4 seconds, virtually identical to FF 3.6.16. Takes about 2 seconds into Chrome on the same client. The client is a win 7 64-bit ASUS U30JC-B1 laptop.
Also, loads into IE8 via http://localhost/ext-4.0.0/examples/themes/index.html in about 5 secs. This is a win 7 64-bit Ultimate desktop with core i7 CPU (2.67 GHz) and 12 GB RAM. Of course, on this machine Chrome only takes about 1.5 sec.
IE8 does it in 5 seconds, Firefox 4 is a bit faster (some 3 seconds) and Chrome is indeed wonderful, 1,5 seconds.
I'm using Windows 7 Professional x64.
Ext JS Premium Member
A couple of observations from playing around with my grid config:
- Chrome: not too bad, although 1 second to show a scrollbar after grid render isn't something I'd be selling as a massive performance improvement.
- Firefox: see Chrome
- IE: forceFit: true = 10 seconds from loadMask hide to scroller visible
- IE: forceFit=false, flex on all columns = 10 seconds
- IE: forceFit = false, no flex, fixed column widths adding up to less than panel width = 4 seconds
- IE: window resize triggers same behavior as load with grid present
I notice that, when profiling IE, we spend a LOT of time in Ext.view.Table.onHeaderResize (7 seconds for a render, in my case), which spends a lot of time in restoreScrollState.
Comparing Chome vs IE 8 on the Desktop Sample App (and my own app) the amount of CPU usage under IE8 and EXTJS 4.0 is far higher than what Chrome is consuming. (Id expect to see some differences because of browser architecture) However... this is problem. Do the same test on 3.3 and IE 8 is actually using a little less CPU than Chrome.
I'd be interested to know what the official line on this is. Currently in terms of releasing a commercial EXTJS 4.0 based App, I'll have to detect IE and advise the end user it's not compatible. This would really limit my target audience down the Chrome and FF, which is not a great position to be in.
Please advise if the IE performance issues are being tracked / worked on and do you expect to resolve them?
Just a thought... Could the performance issues in IE be due to DOM vs InnerHTML?
Has this changed under 4.0? DOM in IE performs very poorly, where as InnerHTML performance across the main browsers is comparable.
Sencha - Ext JS Dev Team
No, unless you've explicitly set useDom to be true.
I don't really notice much difference when loading the examples. Obviously IE is slower than Chrome/FF because it's an inferior browser, but I'm not seeing anything like the 30 second load times you've mentioned. Seems like other users (above) haven't been able to either.
Twitter - @evantrimboli
Don't be afraid of the source code!
Originally Posted by evant
Hi, I'm not setting useDom to True.
The really interesting thing is, like you say IE is inferior to Chrome and FF however under 3.3 the that was not very noticeable at all.
My dev box at home is a P4 3.5GHz Intel running on Win XP 32 bit, which gives the most noticeable performance issues. I have tried IE 8 and other peoples systems and IE always comes off a badly. On the very higher spec systems the IE difference is (as noted by other replies on this thread) plus 4 / 5 times that of Chrome. On a system that is more in keeping with the real world an app that takes 5 seconds to render on Chrome would be 4 / 5 slower in IE, e.g. 25 seconds!
The next problem is once IE has rendered the application, the experience is very sluggish indeed. The bigger the App, the more sluggish it gets. Again under 3.3 that problem didn’t exist.
I’m simply comparing the same browser on the same box against 3.3 and 4.0. So as far as diagnosing issues that’s a very valid and clean method.
Side by side IE 8 EXTJS 3.3 and 4.0, the latest release comes off very badly indeed, in fact not fit for purpose.
Please don’t take my comment the wrong way, I’m not purposely slating 4.0, I actually really need 4.0 to make my app a success and always planned to move from 3.3 to 4.0 as part of the dev cycle. Knowing that 3.3 didn’t have every thing I needed and 4.0 would give superior performance. As I said, no offence is intended and I know how much hard work has gone into 4.0 but IE is a very real problem.
@MrSparks, as I posted earlier, I'm not seeing extreme load times with IE8 and EXTJS 4.0 From my post #11 above:
Perhaps it would be useful to try to determine what is different about your IE8 config as this may be the root cause of the performance you are experiencing. That is, EXTJS 4.0 does something differently than 3.3 and on your machine this causes extreme performance problems.
@Rich02818: Chrome 1.5 > IE 5 Seconds is a 70% drop in performance that didn't exist in 3.3. That’s a huge difference and as the application gets bigger the more noticeable the difference is.
Originally Posted by rich02818
So a large app that takes 5 Seconds under Chrome is going to take 17+ Seconds in IE. I say 17+ because the drop is not linier, based on my observations, the bigger the app gets the worse the performance drop gets. As I said in an earlier post, that’s not the end of the issues, IE sufferers the same drop in performance in terms of UI responsiveness once the app has rendered.
p.s. I'm more than happy to work with the Dev team on this, supply exact performance data to help resolve the issue / anything else that might help. Do you have a preferred method of measuring browser performance against the framework? I've purposely not been using firebug etc because they place a varying overhead and would skew the results.