Not sure if this is related, or if the problem is with jquery, jquery- ui, the way we are using them or just IE, but we too are experiencing problems with IE and growing memory use. Our application is heavyish, uses lots of jquery-ui dialogs, and runs within one html page for long times without reloading. We're starting to have problems with IE (7), its memory consumption grows quite fast while using the app, and it quickly becomes sluggish to use.
I've created a simple test page at http://linux.kytomaki.com/jqtest/. It creates empty jquery-ui dialogs and then immediately destroys them. The test uses jquery-svn-trunk rev 6320 and jquery-ui 1.7.1. Monitoring memory usage from Windows XP task manager: On IE 7 consumption starts from 38M after loading the page. After creating and destroying a dialog 100 times on one run, the consumption ends up to 72M. Refreshing the page doesn't seem to have effect on it. Minimizing and restoring the IE window takes mem to 10M, after which refresh of the page takes it to 44M. Doing another 100 dialog create- destroy-cycles takes it to 73M. With IE 8, mem usage starts from 21M. 100 create-destroy-cycles takes it to 55M, so again memory seems to be leaked. This time, page reload frees some memory bringing it to 30M, but now the page minimize- restore-trick doesn't to do anything. Freeing memory by reload doesn't help our case, since the app works within one page that shouldn't be reloaded. Anything obviously wrong with the test case that might cause the problem? -Janne On 23 huhti, 12:11, DBJDBJ <dbj...@gmail.com> wrote: > I personaly will always call CollectGarbage() on window.unload if page > is in IE and full IE8 enviuronment is not detected ... > > Here is why.I will make it obivous, since hardly anyone bothered to > read ;o) > > http://blogs.msdn.com/ericlippert/archive/2003/09/17/53038.aspx > > Crucial paragraph for us today : > > "... The CLR GC is also mark-n-sweep but it is generational – the more > collections an object survives, the less often it is checked for > life. This dramatically improves performance for large-working-set > applications. Of course, the CLR GC was designed for industrial-grade > applications, the JScript GC was designed for simple little web > pages. ... " > > So in 2003 M$FT implemented JScript GC for "simple little web > pages" ... the policy which we are suffering with in 2009, in IE6 and > IE7. > > Also, > herehttp://blogs.msdn.com/gpde/pages/javascript-memory-leak-detector.aspx > , we are being convinced that due to numerous patches IE6 and IE7, > memory leaks have been all sorted , beside a removeChild() problem. > > Also herehttp://blogs.msdn.com/heaths/archive/2005/06/06/425709.aspx, > is another very interesting M$FT text from 2005. Apparently VBscript > has no memory loss problem at all. Nice to know ;o( And yes, after all > CollectGarbage() should be called to avoid "deadlocks" ? what " > deadlocks" ;o( ? > > Ok, to put things in perspective, jQuery might find itslef on a > windows machine. Where it will NOT have IE8 installed and on top of > that it might NOT run "inside" IE6 or 7 at all. It might run "inside" > mshta.exe or just as an windows js file. often used together with WMI > scripting, WSH objects etc ... > > Conclusion: jQuery 1.3.2 will have all possible measures in place to > minimize the IE6 and 7 (or otherwise) memory leaks. Apparently IE8 has > no leaks. The only problem being that almost *all* companies will not > have IE8 allowed before the end of 2009 or even latter. > > So one should use jQ 1.3.2 with all anti mem leak measures. Nothing > else can be done. If and when everyone goes IE8 the probem should be > (will be?) gone. > > So to repeat once more : > I personaly will always call CollectGarbage() on window.unload if page > is in IE and full IE8 enviuronment is not detected ... > > -- DBJ > > On Apr 23, 8:46 am, Danny Tuppeny <danny.tupp...@gmail.com> wrote: > > > After much messing around, I've come to the conclusion Drip is indeed > > flawed. If the Explorer toolbar is returning the same results, I can > > only assume it's also broken. > > > I wondered if maybe IE8 was just better at finding these leaks, but in > > IE6 and IE7 they also don't seem to exist. > > > Using a script similar to Henry's, in Drip the memory shot up and I > > ran out of memory in around 2 minutes. Running the same page in IE8 > > itself didn't affect memory *at all*. No matter how long I left it, it > > never went up. > > > I tried the same thing on another PC using IE6, and got the same > > results. > > > This is quite frustrating, because now we have to find real leaks > > within a huge list of fake leaks that Drip (or the IE toolbar) > > reports :-( > > > On Apr 22, 8:38 pm, Brandon Aaron <brandon.aa...@gmail.com> wrote: > > > > Ahh, thanks. Okay I see the other leaks with this toolbar. I still don't > > > see > > > the leaks in IE6 though. There are a few other places that we need to null > > > out some orphaned node references. Couple in Sizzle and a couple in > > > offset. > > > Should have a patch soon. > > > -- > > > Brandon Aaron > > > > On Wed, Apr 22, 2009 at 1:48 PM, pete higgins <phigg...@gmail.com> wrote: > > > > > We stumbled upon this: > > > > >http://blogs.msdn.com/gpde/pages/javascript-memory-leak-detector.aspx > > > > > It seems to be reporting the same type information Drip is. I cannot > > > > attest to it's accuracy, but it claims as of trunk (it is still in > > > > svn, right?) [6319] I see "leaked" elements listed: > > > > > <div> > > > > <script> > > > > <div> > > > > + <a> > > > > <html> > > > > + <div> > > > > > (the + is to indicate [i presume] the leaked node is within some other > > > > node?) > > > > > My testcase is: > > > > > <html><head> > > > > <script src="jquery.min.js"></script><title>yo</title> > > > > </head> > > > > <body><h1>hi</h1></body></html> > > > > > Prior to svn up'ing just now, It was leaking the "full list" the > > > > original > > > > post. > > > > > Also, unless I'm missing something, I am seeing 91 IE6 unit tests > > > > failures in tests/ > > > > > Regards, > > > > Peter > > > > > On Wed, Apr 22, 2009 at 12:32 PM, Danny Tuppeny > > > > <danny.tupp...@gmail.com> > > > > wrote: > > > > > > Thanks for the response Henry. I was wondering myself if pseudo-leaks > > > > > were being misreported, but I didn't get chance today to test this > > > > > outside of Drip. > > > > > > I'll see if I can reproduce this outside Drip using TaskManager and if > > > > > I can still reproduce, I'll post a new thread with a test case and > > > > > more details. > > > > > > On Apr 22, 1:47 pm, Henry <rcornf...@raindrop.co.uk> wrote: > > > > >> On Apr 22, 9:01 am, Danny Tuppeny wrote: > > > > > >> > Here's a small sample page that seems to leak in the same > > > > >> > way as jQuery: > > > > > >> > <html><head><script type="text/javascript"> > > > > >> > function leakMe() { > > > > >> > var div = document.createElement("div"); > > > > >> > document.body.appendChild(div); > > > > >> > document.body.removeChild(div);} > > > > > >> > </script></head><body onload="leakMe();"></body></html> > > > > > >> > The docs for Drip say that removeChild is just a psuedo-leak > > > > >> > and will be cleaned up when the page is unloaded, but that > > > > >> > doesn't happen. If you set the above page to Auto-refresh > > > > >> > in Drip, memory usage just goes up and up forever. If you > > > > >> > can find a way to stop that happening in the small sample, > > > > >> > I suspect fixing jQuery will be easy. > > > > > >> There is a problem here but I suspect that problem is with Drip and > > > > >> not IE or JQuerry (there may be problems with IE and/or JQuery but if > > > > >> so they are not being demonstrated here). > > > > > >> Starting with the following more extreme example of the - appendChild > > > > >> -, - removeChild - sequence; appending 100,000 DIVs, stopping with an > > > > >> - alert - (to give the opportunity for garbage collection to run and > > > > >> memory use to be examined), removing all of those DIVs from the DOM, > > > > >> stopping again, and then repeating/looping the process, should, if > > > > >> the > > > > >> memory leak issue exists (in relation to - removeChild - use) result > > > > >> in ever increasing memory consumption, which should be noticeable > > > > >> using crude examination techniques (such as reading the iexplorer > > > > >> process's "Mem Usage" in Task Manage) due to the number of DIVs > > > > >> created. However, using this test page:- > > > > > >> <html> > > > > >> <head> > > > > >> <title></title> > > > > >> <style type="text/css"> > > > > >> </style> > > > > >> </head> > > > > >> <body> > > > > >> <script type='text/javascript'> > > > > >> function createDivs(){ > > > > >> var div; > > > > >> for(var c = 0;c < 100000;++c){ > > > > >> div = document.createElement('DIV'); > > > > >> document.body.appendChild(div); > > > > >> } > > > > >> alert('Divs set'); > > > > >> setTimeout(clearDom, 3000); > > > > > >> } > > > > > >> window.onload = createDivs; > > > > > >> function clearDom(){ > > > > >> while(document.body.lastChild){ > > > > >> document.body.removeChild(document.body.lastChild); > > > > >> } > > > > >> alert('Divs cleared'); > > > > >> setTimeout(createDivs, 3000);} > > > > > >> </script> > > > > >> </body> > > > > >> </html> > > > > > >> (The 3 second delay between function calls is to give you time to > > > > >> close the browser when enough has been seen) > > > > > >> - running in IE 6 (on XP) gives an oscillating (by about 9 megabytes) > > > > >> "Mem Usage", with no overall accumulation of memory consumption as > > > > >> the > > > > >> script continues to add and remove DIVs, and running in IE 8 (on XP) > > > > >> showed the memory use increase with the first addition and then stay > > > > >> at about that level. What I did not observe at all was any steady > > > > >> increase in memory use, as would be expected if a memory leak issue > > > > >> existed here. > > > > > >> This suggests that IE's garbage collection is successfully dealing > > > > >> with this situation without even getting to the point where > > > > >> re-loading > > > > >> the page is significant. > > > > > >> On the other hand, running the same code in Drip (with the number of > > > > >> DIVs created reduced to 10,000 because Drip slows the script down > > > > >> considerably) showed a steady increase in memory consumption. > > > > >> Consuming more each time the DIV addition-removal cycle was executed. > > > > > >> This would lead me to conclude that:- > > > > > >> 1. The rumours of issues relating to the use of - removeChild - are > > > > >> unsubstantiated and so should be ignored. If they do relate to a > > > > >> memory leaking cause and effect relationship then the - removeChild - > > > > >> use is not (in isolation, or directly) the cause of whatever effect > > > > >> is > > > > >> being observed. > > > > > >> 2. Drip should not be regarded as a definitive indicator of memory > > > > >> leak issues as it appears to directly provoke some of the issues it > > > > >> attempts to report. > > > > > >> 3. Any supposed memory leak issues with JQuery should be demonstrated > > > > >> in isolation else time and (script) performance could be squandered > > > > >> attempting to 'fix' non-issues.- Hide quoted text - > > > > > >> - Show quoted text -- Hide quoted text - > > > > - Show quoted text -- Hide quoted text - > > > - Show quoted text - --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "jQuery Development" group. To post to this group, send email to jquery-dev@googlegroups.com To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~----------~----~----~----~------~----~------~--~---