Thanks for the suggestions. I've tried CollectGarbage before, and it doesn't seem to make any noticeable difference. I updated the test page to include call to CollectGarbage every 30 secs.
Changing the document compatibility mode didn't have effect on IE8. Just renaming the index.html to index.hta and running it locally adds a process "mshta", whose memory allocation pattern on a xp system with IE7 is similar to that of IE7 running the application over http. Any other ideas? -Janne On 24 huhti, 15:51, DBJDBJ <dbj...@gmail.com> wrote: > 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 > > ... > > lisää » --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
