This guy (from M$FT Global Product Development, whatever that is) : http://blogs.msdn.com/gpde/pages/javascript-memory-leak-detector.aspx
evidently claims that all the IE versions prior to 8, have been pached up and that IE8 has no leaks. *AND* that the only remaining issue is with removeChild() and that this is not actually a mem leak ... ;o) My counter claim is that he (and they) better start talking and sorting their JScript GC. It seems from your and other report they still have (at least) 3 GC's : for JScript for VBscript and for CLR (aka .NET). And on several M$FT hosted blogs we can read how VBscript mem usage is simpler and better. And most importantly how CLR GC is completely different (http://blogs.msdn.com/maoni/ archive/2005/10/03/so-what-s-new-in-the-clr-2-0-gc.aspx) and conceptually and practicaly proven to be better (generational vs. clean-and-sweep)... It seems you are not using it, and I think we should discard DRIP and use (M$FT's own) very good proc explorer. (http:// live.sysinternals.com/) This way we can credibly monitor any browser and see very nicely what is going on. And more importantly we can measure the effects of jQuery patches. Also, I would be very interested if you can run your one page as an HTA, and then report on its mem spending habits? Also, please do not feel offended if I ask you if you file begins like this : <!DOCTYPE html> <html> <head> <!-- Set document compatibility mode to IE8Mode --> <meta http-equiv="X-UA-Compatible" content="IE=edge" /> My experience is that only with this prolog we have expected IE8 behaviour and features present. And last but not the least, this very bad practice and desperate measure, might help: if ( "function" === typeof CollectGarbage) setInterval( 60000, CollectGarbage ) ; --DBJ On Apr 24, 9:45 am, Janne Kytömäki <janne.kytom...@gmail.com> wrote: > 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 athttp://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 > > ... > > read more » --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
