PDA

View Full Version : On performance



edspencer
23 Jul 2011, 10:11 PM
A number of people have been asking about slower performance with Ext 4 compared to 3.4. Usually the problems center around IE8 but all browsers are somewhat affected. The effect is definitely there, and it comes out of an architectural change made in 4.0.

Whereas in 3.x most components rendered themselves in a different manner, 4.x unifies the rendering and layout pipeline, yielding a much more robust architecture. For example in 3.x the tool icons in a Panel header would just be thrown in as a string by Panel's render function. In 4.x they - and everything else - are all true Components and participate in the layout system.

That's obviously a good thing, but there's also a performance penalty incurred by splitting the application down into so many components. Even though the browser is doing the same amount of work each way, the order that work is done in can dramatically affect the performance of the application. The finer grained the reads and writes to the DOM are, the worse the browser's style cache performance becomes, and the slower the app renders and lays out.

This is deep within the bowels of both the framework and the browser and the layout engine in 4.0 does not fully take this effect into account. We understand the problem and are working on the solution as the framework's first priority. The 4.0.x branch has seen a large number of performance improvements already but we expect 4.1 to be significantly faster.

MrSparks
24 Jul 2011, 2:01 AM
@Ed

Thank you for the posting a public update regarding the 4x performance issues. Its a huge relief to hear that you have located the root cause and fixing the issue is 1st priority of the development team.

I'm now comfortable enough with the above knowledge to continue developing my commercial app under 4.x, without the fear that framework will ultimately let me down.

Looking forward to the 4.1.x release cycles and performance increases.

Best
MrSparks

danigoldman
27 Jul 2011, 6:36 AM
Is the increase in my browser's memory usage when using ExtJS 4 related to the problem you're describing?

We've noticed that when ExtJS 4 is used (both in sandbox and compatibility modes) that the browser's memory usage shoots up to more than 1.2GB of RAM after just a couple of hours. We've observed it in Firefox when using Firebug. The increase in memory usage makes our product slow and unresponsive, and requires a browser restart every few hours.

This issue has been happening to us even when just a simple ExtJS 4 chart is used, which causes me to believe that it's less of a memory leak problem caused by our code, but perhaps an issue with the framework itself.

sajohns4
29 Jul 2011, 10:21 AM
Firebug is most likely the problem with your memory issues...they've posted a few comments about memory issues on their site.

there were a few bugs in some versions of 4 that were mem leaks...4.0.5 is looking much better as far as performance though. as always...everything in chrome is excellent

praveen_madupathi
29 Jul 2011, 12:01 PM
@edspencer

My sample app is being developed using 4.0.2a and it is working fine in FF and chrome, but IE is too slow, Could you please provide some tentative release date of 4.1.

@Sajohns
Where can i get version 4.0.5.

sajohns4
29 Jul 2011, 12:08 PM
you have to be a premium support member...but you'd go here to get it:

http://support.extjs.com/

edspencer
29 Jul 2011, 12:54 PM
@edspencer

My sample app is being developed using 4.0.2a and it is working fine in FF and chrome, but IE is too slow, Could you please provide some tentative release date of 4.1.

Tentative is the right word, but I'm expecting it to be weeks, not months. Will share more as we get closer. The performance gains in 4.1 are starting to look really good

Christiand
2 Aug 2011, 2:42 AM
Is the increase in my browser's memory usage when using ExtJS 4 related to the problem you're describing?


Run your application with Chrome, in production mode (no debugger). You can shift+esc to open Chrome "task manager" which display the total size of each tab in memory. Keep the task manager open and play around with your app.

SebTardif
22 Aug 2011, 11:04 AM
Under 4.0.2a, byClassName is the slowest function under UI 8 when loading a grid panel.

I have attached the IE 8 profiling.

Is it something fixed in 4.1 performance fixes?

Animal
22 Aug 2011, 6:01 PM
I suspect that is Table View's onHeaderResize being called every time a header has its width set. That has these DomQueries:



el.select('.' + Ext.baseCSSPrefix + 'grid-col-resizer-'+header.id).setWidth(w);
el.select('.' + Ext.baseCSSPrefix + 'grid-table-resizer').setWidth(me.headerCt.getFullWidth());


This is another one of the areas which I have looked into recently. Only resize of headers in an already-rendered grid need to do this. Upon initial layout of the ColumnHeaderContainer, each sizing operation performed by the layout should not trigger that.

SebTardif
23 Aug 2011, 5:50 AM
This is another one of the areas which I have looked into recently.

I'm available to test your fix. If you need more info about this issue please ask.

dongryphon
11 Sep 2011, 5:16 PM
See also this post:

http://www.sencha.com/forum/showthread.php?142811