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 - --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
