| Page 1 of 2 | [ 13 posts ] | Go to page 1, 2 Next |
|
I filed a ticket a while ago (http://yuilibrary.com/projects/yui3/ticket/2532270), but since I haven't received any response, I think it's time to try to involve the larger community.
The problem is that Y.Node has a static member called _instances which stores references to all instances of Y.Node. The only way to remove an instance from _instances is to explicitly call destroy(). This forces everybody back to the programming model of IE6 and IE7. Y.Node._instances provides significant value, however, since it ensures that only one Y.Node instance is created for each DOM element -- within each sandbox, of course. I therefore propose an alternative to the global _instances map: On each DOM element, store a mapping from sandbox id's to Y.Node instances. Unfortunately, this does mean one sandbox can in principle access Y.Node instances from another sandbox -- though it does require extra effort. But sandboxes have never been completely isolated, since DOM elements are global and Y.Node itself avoids instanceof in order to allow Y.Node instances to be passed between sandboxes. My patch is here: https://github.com/jafl/yui3/commit/498 ... cf3ce539c1 I would appreciate feedback on whether this is an acceptable replacement for Y.Node._instances. |
Juan Ignacio DopazoYUI Contributor
|
jafl wrote: I would appreciate feedback on whether this is an acceptable replacement for Y.Node._instances. I don't think so. This would be a circular reference that older browsers probably won't know how to deal with. I think the answer would be to use a WeakMap polyfill instead. I've heard that they're pretty decent at not blocking GC. |
Juan Ignacio DopazoYUI Contributor
|
I take back what I said. Good WeakMap shims are reliant on ES5 features (setting enumerability to false).
|
|
You are correct that IE6 and IE7 would not understand the circular reference. However, all the newer browsers would garbage collect it.
This is still far better than the current situation where *all* browsers fail to garbage collect it because it is stored in a global list. As you can see from my changes, I am not suggesting that we remove Y.Node.destroy. It is necessary to avoid leaks in IE6 and IE7, for those who still need to support those browsers. But more and more site are dropping support for those ancient browsers, and YUI 3 should not force them to worry about GC. |
Juan Ignacio DopazoYUI Contributor
|
jafl wrote: It is necessary to avoid leaks in IE6 and IE7, for those who still need to support those browsers. Well, YUI still needs to support those browsers, so I don't think it belongs in the core library. Is it monkey-patchable? |
|
I think you misunderstand. My patch does not break support for IE6 and IE7. All YUI needs in order to support IE6 and IE7 is the function Y.Node.destroy. My patch simply makes Y.Node.destroy unnecessary if an app is targeting only newer browsers.
|
|
Sorry about not being responsive to this topic. I did some testing last year on various caching approaches, and the DOM-based caching in general seemed the best alternative for all but IE <=8.
Its not quite as straightforward as hanging the instance(s) on the DOM node for all browsers however, as this compounds the memory problem in IE, so we will likely need to continue the off-DOM cache for those browsers. Look for something to land in 3.7.0 to address this issue. Ideally I can just merge in John's patch, however there will likely need to be a forked implementation for IE <= 8. |
Juan Ignacio DopazoYUI Contributor
|
jafl wrote: I think you misunderstand. My patch does not break support for IE6 and IE7. All YUI needs in order to support IE6 and IE7 is the function Y.Node.destroy. My patch simply makes Y.Node.destroy unnecessary if an app is targeting only newer browsers. You're very much right, sir. msweeney wrote: Look for something to land in 3.7.0 to address this issue. Ideally I can just merge in John's patch, however there will likely need to be a forked implementation for IE <= 8. What's your plan for IE <= 8? Maybe we can help speed it up. Memory is probably going to be an issue soon if the App framework makes single page apps more popular. |
|
I'll take a stab at integrating an IE version into the patch.
|
|
In IE, would it be sufficient to null node._yui_instances when it is empty?
BTW, Y.Node already hangs _yuid off every DOM element, so doesn't that leak, too? |
| Page 1 of 2 | [ 13 posts ] | Go to page 1, 2 Next |
| You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum |
© 2006-2013 Yahoo! Inc. All rights reserved.
All code on this site is licensed under the BSD License unless stated otherwise.
About This Site · Security Contact Info
Powered by phpBB® Forum Software © phpBB Group