PDA

View Full Version : Mitigating IE memory leaks



george4kenco
11 Aug 2009, 9:16 AM
We have an application that spawns several ExtJS windows depending on which grid field you click, and sometimes clicking something in the window itself can result in another Ext window.

Even in the simplest case though we've noticed that opening and closing a single one of these windows is resulting in pretty significant memory leakage under IE7, such as 5MB leakage per open/close. Its not happening with FF3 however so it seems like its the well known IE issue, e.g. (in a nutshell) how they manage Javascript and DOM separately.

Regardless I'm wondering a few things, such as whether its ExtJS itself or the way we're using it that is causing the issue. And whether there is some ExtJS functionality that we could possibly use to mitigate this. Based just on the name and what I know about the design pattern, I'm wondering if might not want to use Ext's "fly(weight)" functionality to manage these windows?

Any advice in general as to how to mitigate these IE specific memory leaks would be appreciated. I'm using sIEve to capture some data which I can analyze. I will say that it seems my use case (simply opening/closing one of these popups) is result in a proliferation of what sIEve calls "orphaned" elements; see http://home.orange.nl/jsrosman/sievehelp.htm These might not be "leaks" in the sense that these might get cleaned up onunload, but this doesn't help if our users keep their browser open for extended periods. And 5 MB per open/close can build up to 100s of MB pretty quickly, and if some of these users are on older systems with only 512 or 1024 MB of RAM, thats pretty significant.

Again, any advice as to how to mitigate memory leaks in IE when building ExtJS applications, and or tools for measuring and analyzing such leaks, is appreciated.

tryanDLS
11 Aug 2009, 10:14 AM
Are you using the latest 2.3 version?

Flyweight pattern doesn't really apply here as that's just how Ext gets a 'throwaway' ref to an element.

The resolution in general depends largely on your code. If you're building windows containing items that the Ext Component architecture doesn't know about, they're probably not getting cleaned up. Also, you should look at whether you can simply hide windows and reuse, rather than create/destroy multiple windows. There are a number of threads that discuss some of these concepts. If you post some sample code, maybe somebody can give you some suggestions.

Condor
11 Aug 2009, 10:17 AM
Do not measure the memory leaks by the memory usage of the browser (it has delayed garbabe collection). You can indeed best use sIEve to check for memory leaks.

Are you by any chance rendering components inside the window? Do NOT do that. Let the container layout render the components (the container is also responsible for removing them when needed).

george4kenco
11 Aug 2009, 10:32 AM
Thanks Tim/Condor I will take into consideration the various things you mention. In particular I'm going to looking into hiding windows instead of destroying them. I'd done that on a contract earlier this year, but have more or less inherited the current code base where we are instead destroying the window and always creating a new one.

I'm writing some scripts for sifting through the output from sIEve and might either post some of those scripts if they might be helpful to the community, or particularly the results especially if I mitigate the issue by hiding and re-using the windows. If you haven't tried working with the data that you can "copy" from sIEve, it generates way more output than what is shown in their grid, so working with it is probably going to require more than cygwin's awk/grep, I'm probably going to have to use "Minimal Perl" especially because of it's "paragraph mode"

In any event we are not yet up to version 2.3 but rather still on 2.2.1

george4kenco
11 Aug 2009, 11:30 AM
You should look at whether you can simply hide windows and reuse, rather than create/destroy multiple windows.

Ok, this definitely seems like it is going to help tremendously. The changes I had to make were simple and few but they greatly reduced the number of "orphans" reported by sIEve. Previously there were so many I copied them all to the clipboard and then came up with the following regular expression from the cygwin command line to count them:

$ egrep '\([0-9]+ reference[s]?\)' after_one_driver_update_click.txt | wc -l
58

$ egrep '\([0-9]+ reference[s]?\)' after_five_driver_update_clicks.txt | wc -l
209

Those are how many "orphans" sIEve was reporting when we were creating/destroying the windows. Before even one "driver_update_click" there were just 3 and you can see they greatly increased.

After switching to hiding/re-using just this one window, the number of orphans was so much lower that I could see easily just count them from within sIEve's "Show In Use" grid; they only jumped to 5-8 orphans instead of up the 58-209 we had previously reported. We still have a couple of issues to work out with the function that we now need to execute 'beforeHide' instead of 'beforeClose', but I definitely have something positive to report to management now

Thanks!!