RE: Loading Dom nodes into Memory - best practise
"Lon Boonen" <[email protected]> Mon, 15 May 2006 18:56:42 +0200
| Newsgroups | gmane.comp.web.dom.wdf |
|---|---|
| Message-ID | <[email protected]> |
you have to understand how this memory leak works. you can without a problem attach dom objects to js objects, that isn't the problem. there are ample pages about this. read them. i find onunload detach very tedious and unsafe. understanding works a lot better. ________________________________ From: [email protected] on behalf of Dave Cline Sent: Mon 15/05/2006 18:29 To: [email protected] Subject: Re: [wdf-dom] Loading Dom nodes into Memory - best practise We found that IE leaks profusely when attaching dom objects to javascript objects. And the the dynamic attachment of event handlers also caused leaking. What we did to minimize this was to create a global cache where javascript objects where stored which had had dom objects and their associated events rigged. On window.unload we would loop through this cache and unhook DOMjects from Jobjects also setting the DOMjects events to null. Bring up you task manager's process list and watch you browser's memory as you refresh over and over. If it climbs but then levels out you should be fine. If it never stops climbing you'll have to find your leak. The best way to do this is to start simple and keep adding chunks of your code until the leak is evident. Regards, Dave Cline On 5/14/06, Lon Boonen <[email protected]> wrote: > > To Ian > > instead of refreshing a few hundred times you should attach a 10MB string > to each DOM node you are storing. Then refreshing a single time will be > conclusive if you take a look at Task Manager. > > How to build a 10MB string? Join a couple of arrays. It's fast and very > obvious. > > To Richard. > > Have you measured the time needed for DOM traversal before you started > this dom-nodes-storage-quest? > It's very, very probably negligable. > I myself never attach an event handler to anything but the > documentElement. On each click I traverse the DOM looking for the level that > is interested in handling the event. Time required is completely negligable. > > Just my thoughts. > > groetjes Lon > > > ________________________________ > > From: [email protected] on behalf of Ian Petersen > Sent: Sun 14/05/2006 19:06 > To: [email protected] > Subject: Re: [wdf-dom] Loading Dom nodes into Memory - best practise > > > > Hi Richard, > > Instead of just leaving the page open in your browser for a long time, > try refreshing the page several hundred times. > > Holding DOM nodes in memory can cause a memory leak if you have any > circular references in your data structures. The simplest circular > reference is a Javascript object that points to a DOM node that points > back to that same Javascript object. Any circle is a problem, though, > so introducing extra Javascript objects or extra DOM nodes into the > circle doesn't solve the problem. > > One particularly nasty trick in this problem is that event handlers > can be part of the circle. Functions are Javascript objects and, when > they are closures, too, they can have references to other objects > (including DOM nodes). (In case you've never heard of a closure, it's > basically a nested function.) > > If you can refresh your test page a few hundred (or a few thousand) > times without crashing the browser, you're probably OK. If the > browser eventually crashes, then you'll need to break the circular > references somehow. You can either redesign your page to not create > the circles in the first place or you can add unload handlers that go > around breaking links as the browser dismantles the page. > > Ian > > On 5/14/06, Richard Garbutt <[email protected]> wrote: > > Hi, > > > > I'm working on a project where I'm manipulating elements on the page > > in response to user input. I've created objects which load the > > elements to be manipulated as member variables on page load. The > > objects provide an interface to manipulate the elements they are > > responsible for. The event handlers use this interface. > > > > This approach makes event handling very responsive, as no dom > > traversal is needed when the event fires. (Or very little - sometimes > > I use firstChild or previousSibling.) > > > > I'm wondering if there are any problems caused by loading dom nodes > > into browser memory and leaving them there for as long as the page is > > open in the user's browser. I'm loading about 20-50 nodes like this. > > Leaving the page open in Firefox and IE for several hours doesn't seem > > to cause any problems - but I have plenty of memory. > > > > regards, > > Richard > > > > > > > > Unsubscribe > > [email protected] > > > > List info > > http://www.quirksmode.org/dom/list.html > > Yahoo! Groups Links > > > > > > > > > > > > > > > > > -- > Tired of pop-ups, security holes, and spyware? > Try Firefox: http://www.getfirefox.com > > > > Unsubscribe > [email protected] > > List info > http://www.quirksmode.org/dom/list.html > Yahoo! Groups Links > > > > > > > > > > > [Non-text portions of this message have been removed] > > > > > Unsubscribe > [email protected] > > List info > http://www.quirksmode.org/dom/list.html > Yahoo! Groups Links > > > > > > > -- Dave Cline www.davecline.com/ [email protected] [Non-text portions of this message have been removed] Unsubscribe [email protected] List info http://www.quirksmode.org/dom/list.html Yahoo! Groups Links [Non-text portions of this message have been removed] ------------------------ Yahoo! Groups Sponsor --------------------~--> Home is just a click away. Make Yahoo! your home page now. http://us.click.yahoo.com/DHchtC/3FxNAA/yQLSAA/9rHolB/TM --------------------------------------------------------------------~-> Unsubscribe [email protected] List info http://www.quirksmode.org/dom/list.html Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/wdf-dom/ <*> To unsubscribe from this group, send an email to: [email protected] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/