Andreas Junghans schrieb: > Am 02.08.2006 um 07:10 schrieb Sebastian Werner: >> We have detected that with the enabled disposer, and that's important, >> the memory leaks in Firefox a less. > > OK, then let's keep the disposers for all browsers. I simply wasn't > aware of the problem as Firefox is much better at hiding it from the > user than IE ;-) > >>>> Please remember however that "dispose" isn't a memory management >>>> tool. >>>> To just dispose doesn't free up memory. This means that long-running >>>> application could be problematic (these applications generally >>>> creates >>>> even more objects while running: events, io-stuff, tooltips, ...). >>>> Just >>>> dispose them, doesn't free up memory. So it will increase over the >>>> runtime of the application. This is just normal I think. >>> Not quite my point of view :-) I think an application should be able >>> to run continuously without ever-increasing memory usage. An initial >>> increase is normal, but there has to be a plateau somewhere, not an >>> ever-growing mountain. >> Good intention, but just not realistic in my opinion. Each newly >> created >> object theoretically defines new data. This is true for events, >> xmlhttp-requests and many other stuff. As we have no control over the >> memory managment of the browser, why do you think the browser directly >> free-up memory of the old xmlhttp-requests etc. while creating new >> ones? > > Sure, there's no direct control over the garbage collector. But if > there are still references to objects after disposal, it's absolutely > _impossible_ that they're collected. Shouldn't we at least give the > browser a chance to free them up? > > IMHO, qooxdoo shouldn't leave uncollectable objects hanging around > after they have been "disposed" (don't know if this is actually the > case, but it sounds like it from your previous comments).
No that's not the case. qooxdoo's disposer logic works almost perfect. There are currently no big memory leaks detectable with qooxdoo. Sure, dispose mean, for us our job is done. We have no control, but as you mentioned, we give the control back to the browser and remove the affected references. So the browser can run it's garbage collection. > >>> As for "dispose doesn't free up memory": Of course it does (or at >>> least it should). IMHO, when you dispose an object, all references >>> from it (and also to it, at least as far as internal qooxdoo stuff >>> like the object db is concerned) should be removed so that the >>> garbage collector can reliably kill it. This way, you can create and >>> remove widgets dynamically as much as you like. If qooxdoo really >>> doesn't allow that, I think that is a bug and should be fixed. >> This is not a problem of qooxdoo nor any other library around. The >> garbage collector just don't work while being on the same page. >> Especially in Firefox. > > Not true. I just did a quick test where I created lots of objects and > put them into an array. For one test round, I created 10 of these > arrays and retained references to them. For the next round, I also > created the objects 10 times, but this time without keeping the old > references. Guess what, it made a _big_ difference in memory > consumption. Yeah, but in the real world, you will keep the objects in both situations. The question is, if you clear out an array/hash map with from it's values and delete itself afterwards, is the memory consummation afterwards identical to the time, where the array does not exist yet. In my tests this is not the case. Sure, the memory consummation goes down. But it doesn't get back it's original state. But - and here comes the difference - if you leave the page and visit it again, it reach the old value nearly perfect. Maybe the garbage collector does some fast memory freeze after clearing an array, but it doesn't make it really complete. This mean, that as long as you be on this single page, the memory consummation does not shrink down to it's original value. All these don't tell us what's with images, iframes, xmlhttp, dom-nodes, etc. I think there are many things more which could be problematic - not just pure js code. > > I also played around with nulling out references: > > 1.) I created a big object array. This increased memory consumption > by roughly 10 MB. > 2.) I played around with other elements on the same page. Memory > consumption did not change. > 3.) I freed the object array. No immediate change in used memory. > 4.) I played around some more (still on the same page, no reload). > After a while, memory usage decreased by about 10 MB. Interesting effect. That's, as explained above, new to me. Maybe a improvement of recent development in Firefox. Wouldn't it be great IE would do the same. > > All tests where performed in Firefox. There may be leak problems, but > it's plain wrong that the garbage collector doesn't run while staying > on the same page. IMHO, if qooxdoo really keeps accumulating > references (again, I don't know if this is really the case, you just > make it sound like it is), then this is a design flaw. There is no design flaw like this. Maybe we missed some object reference here and there. But generally it seems to work quite well. > >> Maybe browsers are just not designed for that >> long-living pages/applications. Normally the garbage collector only >> runs >> when you leave the page. > > Not true (see above). > >> Even the Microsoft proprietary function (I >> don't remember the name currently), does not free up any memory on >> command. > > I agree that the collector isn't really controllable by the > application, but it does indeed run from time to time, and nulling > out references over the runtime of an application is not in vain. I always hoped so. Maybe we need some more tests with qooxdoo and incremental refreshes (i. e. replace a set of widgets with new ones, background transport using xmlhttp, ...) > >> In the real world we have just no control over the memory management. >> The only thing we could do is to help the browser to be able to >> correctly free up memory. > > Agreed. This is why I think getting rid of references is important > (and not just on unload, but also during run time). I think the same. Cheers, Sebastian > > Regards, > > Andreas > > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys -- and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > qooxdoo-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ qooxdoo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
