Am 01.08.2006 um 20:08 schrieb Erik A. Onnen: > I'm following this thread closely because this is an issue for me as > well. Using a simple test of creating 50,000 Date objects, iterating > and testing first reference nulling then deleting, delete consistently > performed slower although significantly slower on IE. On average: > > Firefox 1.5.0.5 (win64) > reference = null : 78ms > delete : 94ms > > Firefox 1.5.0.4 (linux-x86) > reference = null : 88ms > delete : 110ms > > IE 6.0.3790 (win64) > reference = null : 63ms > delete : 3765ms > > > Admittedly I'm ignorant as to the internals of the IE garbage > collector, but shouldn't simply nulling out the qx.core.Object._db be > sufficient for escape analysis (i.e. if this is the only point of > reachability for these objects, removing it should preclude any it's > contents from being marked as reachable)?
Nulling the references is enough. > Is the IE garbage collector > stubborn such that even though the objects are no longer reachable > they still have to be manually deleted recursively (in which case it's > not really a garbage collector)? The problem with IE's garbage collector is that it has a major bug (although Microsoft doesn't call it a bug ;-)) Every time a cycle between DOM nodes (which are COM objects in IE) and JavaScript objects is formed, no object involved in the cycle will ever be garbage collected, not even when the current page is replaced by another one. This is the one and only reason why dispose code is necessary at all. To break such DOM/JavaScript cycles, qooxdoo (and I suppose similar frameworks too) remove all references when the page is unloaded (or when a widget is no longer needed). Otherwise, there would be major leaks that would make the browser unusable after some time. Besides the leak/cycle problem, IE's garbage collector has another ugly deficiency: It gets awfully slow when there are lots of objects on the heap. They don't have to be actively used, they just have to be there (and reachable via reference chains). For example, a simple "for (x in y)" loop can either be fast (when there are only a few objects) or unbearably slow (when there are many objects). Again, these objects don't have to be used in the loop at all to slow it down! It seems that there are certain actions which trigger the garbage collector, and since the collection happens in the main thread, it brings the whole application to a halt until it's finished. "for (x in y)" seems to be such a trigger. The wildly different times you observed for deleting vs. nulling out seem to indicate that the delete operator is another trigger, while simple "for (i=0;i<x;i++)" loops don't seem to be affected. Maybe it would be worth the effort to find and document all the possible triggers. If they could be avoided (e.g. by caching hash map keys in ordinary arrays to avoid "for (x in y)" loops), qooxdoo's overall performance in IE could be greatly increased. 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
