Andreas Junghans schrieb: > Am 01.08.2006 um 23:09 schrieb Sebastian Werner: > >> Andreas Junghans schrieb: >>> Am 01.08.2006 um 21:44 schrieb Erik A. Onnen: >>> >>>> Andreas Junghans wrote: >>>>> This is the one and only reason why dispose code is >>>>> necessary at all. >>>> Could there not be browser-specific code in the unload to skip the >>>> mass disposal in FF? It's the Stop Script/Continue dialog that's >>>> killing me atm. Or maybe default as is but provide a configuration >>>> hook if users wanted to bypass it for certain browsers? >>> In the past, Firefox had some leak problems too, but I think they're >>> mostly sorted out. Maybe it would really make sense to call the >>> dispose code in IE only. The way it's handled now, it's a bit of a >>> safety net in case other browsers have similar problems. >> Mhh, have you any reference that tell us that? > > Just anecdotal "evidence". Applications we've been developing never > brought Firefox 1.0.7 and up to its knees (even with incomplete > cleanup code after hours of reload after reload). The same code made > IE unusable pretty fast. This is why I got the impression that there > are no significant leaks in current versions.
I'm sorry, but have you ever opened a memory managment tool and take a look at Firefox' memory usage? Yes, Firefox doesn't get slower with the more memory it consumes - as long as there is enough available. It's just unrealistic to think that a browser with so many memory leaks like Firefox don't are problematic (just google ;)). I've seen memory increase of Firefox to 300 MB on my Windows machine, while just running "normal" HTML pages. Closing tabs also doesn't really help here anymore. Firefox 1.5 also seems to have more memory leaks, following the articles and news around the world. I think it's also important to "help" Firefox here. The performance is one thing - the memory consume another (especially because no all surfers enjoy the power of 2GB RAM ;)). We need to be sure, that qooxdoo is not another reason for Firefox' memory increase. We have detected that with the enabled disposer, and that's important, the memory leaks in Firefox a less. In my opinion leaks in browsers are generally only detectable after leaving the current page. Normally it should consume exactly the same memory than. A better however, is to reload the current page/application. The memory consume then, should be the same then after loading it the first time. In the most browser this isn't the case. See also: http://www.squarefree.com/2006/02/04/memory-leak-progress/ http://www.neilturner.me.uk/2006/Feb/05/memory_leaks_in_firefox.html http://forums.mozillazine.org/viewtopic.php?t=354828 http://www.computerworld.com/softwaretopics/software/apps/story/0,10801,111065,00.html > >> 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, normally the initial increase should be much higher than the runtime increase. > > 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. Maybe browsers are just not designed for that long-living pages/applications. Normally the garbage collector only runs when you leave the page. Even the Microsoft proprietary function (I don't remember the name currently), does not free up any memory on command. 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. Logically the same is also true for Dojo, Backbase and Bindows for example. 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
