According to this jQuery UI ticket it is namespaced events that are causing their leaks. http://dev.jqueryui.com/ticket/4188 http://dev.jquery.com/ticket/4241 -- Brandon Aaron
2009/4/24 Janne Kytömäki <janne.kytom...@gmail.com> > > 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 -~----------~----~----~----~------~----~------~--~---
