Thanks for the update. As rich02818 say's, performance across the whole browser range under 4.0.0 is inferior to 3.3 and IE really highlights the issue.
Good look guys.
Printable View
I second what others have posted about performance already - Ext 3 performs better across the board and I'm glad Sencha is now looking into it.
@MrSparks - Thank you very much for the detailed analysis.
I wonder - has anyone done a comparison pitting the different versions of IE8 against each other? I have Windows Vista with IE 8.0.6001.19019 at work and Windows 7 IE 8.0.7600.16.385 on a laptop and throughout the pr and beta cycles I noticed consistent discrepancies between the two in terms of performance and stability. 8.0.6001 consistently exhibited worse performance and even flaky JavaScript errors not present in the newer one. I chalked it up to an older machine or misconfiguration or network or something, but now I'm wondering if there really is a subtle rendering difference between the two that throws 4 off. It might be a moot point since neither was that great but I just post out of curiosity... Is Ext tested with multiple minor versions like this?
Perhaps slightly off topic, but with regard to the IE 8 differences, I posted a problem with the border layout in 8.0.6001 a while back http://www.sencha.com/forum/showthre...layout-example
Just curious - could someone on here testing with IE 8.0.6001 try the portal and border layout examples and post whether they work and how they perform?
Also experience performance issues in IE 7/8/9 compared to Firefox and Chrome.
I am using a Viewport where the Center region is outputting HTML. When I show 6k rows in a table format, Firefox and Chrome handle it fine... but IE slows to a halt.
But it only slows to a halt when the table is displayed INSIDE of the center region. If I just display the HTML with no ExtJS 4 wrapper, it works fine. So there's something within Ext 4 that is crippling rendering time in IE browsers.
Good luck tracking down the issue!
@NoahK17 are you saying that the 6k rows in a table is html and does not create ExtJS components? What happens when you show only a very small html in your center region in IE?
The 6k row "table" is raw HTML, generated via PHP then patched into the center region of the border layout. I'm probably going to re-construct the table to use a Grid Ext component instead to see if that helps.
As to your second question: Smaller tables (hundreds of TD's and TR's) render just fine in all three browsers I've tested (Chrome 6, Firefox 4, IE 9)... it's just IE that stumbles when you get to ~1k rows. Firefox and Chrome handle the content just fine.
I can post a Screenr.com if that helps?
You guys must be wrong, this "is the fastest, most bullet-proof version of Ext JS we’ve ever created"?!
observe similar overall performance issue in IE8 (version: 8.0.6001.18702CO)
loading theme sample page takes more than 30 seconds.
http://dev.sencha.com/deploy/ext-4.0.0/docs/ running very very slow
any update about this issue? have sencha found the root cause? fix? It makes me a really bad position to convince senior managers to use your product.
We had the same problem with our products... our customers gave us so much bad feedback when we upgraded our main product that we had to revert all but a few of them. We also failed in convincing support about the slowness, they didn't want to hear it or address it... it was especially noticeable with IE7, which is the most used browser by our customers (schools/corporate)
We were hoping v4 would fix these issues since performance was so hyped up at the conference... now we're looking at running on an unsupported version (v2) going forward or having to rewrite our products in a different framework which isn't likely
Could this performance issue is partly from ExtJS 4.0 dynamical class loading as the schema sample page is a sample only? Cant believe that Sencha said it rewrite the layout engine to be faster and the fact is it is slower?