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.
If you want to bypass the dispose on unload yourself, you should be
able to do it this way:
qx.core.Object.dispose = function() {};
(In a script block in your HTML page after the qooxdoo script tags.)
You can surround this by a browser switch to still handle IE correctly.
>> 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.
>
> I did some additional google searching after my previous post and
> found some authoritative articles on the subject like:
>
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/
> IETechCol/dnwebgen/ie_leak_patterns.asp
>
> This got me thinking though, is it really necessary to dispose *every*
> object. Alternatively, would it be possible to track circular
> references (say through property mutators on instances/singletons) and
> simply dispose one half of a circular reference thereby freeing the GC
> to clean-up the other half without blocking the unload operation? I
> also thought you could potentially deal with the closure leakage issue
> through the event subsystem detaching listeners on unload.
Maybe this would work. The problem is that it's quite easy to
accidentally create cycles. A first step could be to not blindly null
out everything but let the individual widgets decide what to get rid
of. More manual work, but more efficient. However, I'm not sure how
much faster it would be - maybe the gain is not worth it.
>> 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.
>
> This could be used in conjunction with what I mentioned above. Keep
> one half of a circular reference in a simple array and traverse that
> at unload.
This wouldn't cover the case of dynamically created and destroyed
widgets. Over time, the leaks would grow until the application would
become unusable. By sticking to a strict dispose concept, such
applications can run for a long time without requiring a reload or
browser restart.
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
