Hi,

Sorry, all of the numbers in my original post are off by 1,000. I was
writing "32k" when I should have been writing "32,000k" (or ~31M).
Sorry about that, misread the Chrome memory page and failed to
think. :-)

> But the problem is still there, I don’t know how to release the memory
> used by this.options, using your code, the variable is using almost
> 450 MB in explorer and this memory is never released.

There's something different in your setup, then. When I ran that test
page on my Windows 7 box, IE8 released the memory *much* more
aggressively than that, it never once went above about 57M. You're
really seeing 450MB of memory consumed using the test pages I posted?

Later: I've had IE8 open and running http://pastie.org/1240613 for
about 25 minutes. It's done 4,180 loops, and so created and released
~8,364,180 divs (4,180 x 2,001). It's cycling between about 30M and
50M, which is what it's been doing since I started it. It's very
nearly steady-state, as close to it as I would expect since I'm using
a version of the code that's keeping the TestObject instances (which
won't account for more than a few hundred k). No evidence of a memory
leak at all.

> So, do you have any idea on how to release the memory?

Just what I said above: *You* can't release the memory, you can only
release your references to it (which you are). It's up to IE to
actually reclaim it, _if_ and _when_ it thinks it should. JavaScript
is a garbage-collected[1] environment.

> I really need
> to know how to delete a global variable like this.options

It's not a global variable, it's a property on an object. You delete
it exactly as you originally tried to:

    delete this.options;

At that point, it's down to the JavaScript implementation (IE's
JScript, in this case) to actually release the memory.

In terms of actually dealing with the problem you're seeing, I hate to
say it, but it sounds like you're probably not going to get a quick
fix. :-( You'll have to audit the code, ensure there are no circular
references anywhere (which _will_ cause memory leaks), make sure you
don't have references being kept active by closures (you don't in your
example code, but as we've said, that was just test code), etc.

[1] http://en.wikipedia.org/wiki/Garbage_collection_(computer_science)

Good luck,
--
T.J. Crowder
Independent Software Engineer
tj / crowder software / com
www / crowder software / com

On Oct 22, 3:02 pm, jose maria Cano <josemaria.c...@gmail.com> wrote:
> Hi,
> First of all, thanks a lot for your time and help.
>
> I forgot to say that the problem is using windows and IE8 (of course…)
> but I have to support IE for some clients.
> Also, the class is a test class, is not doing anything “useful”, is
> just to see how to release the memory in IE, the real application is a
> huge application with thousands of nodes, variables, events… and after
> 30 minutes working on IE you have like 500 MB used.
>
> I’ve been making some tests with your code and indeed the memory used
> is the same doing null to the whole array or just doing delete
> this.options
>
> But the problem is still there, I don’t know how to release the memory
> used by this.options, using your code, the variable is using almost
> 450 MB in explorer and this memory is never released.
>
> I don’t know how to attach a screenshot here to show you the memory….
>
> So, do you have any idea on how to release the memory? I really need
> to know how to delete a global variable like this.options and for the
> moment I don’t see how to it…..
>
> Thanks a lot for your time
>
> kr, Jose
> On 22 oct, 14:59, "T.J. Crowder" <t...@crowdersoftware.com> wrote:
>
>
>
>
>
>
>
> > Hi,
>
> > > I have a big problem in my application, when I create a global class
> > > object is impossible for me to release the memory and I'm having
> > > memory leaks.
>
> > It looks to me like you're doing nearly everything you need to do (and
> > a little bit more). Remember that all you can do is make sure that
> > memory is no longer referenced (which it looks to me like you've done
> > almost completely) and that you've broken any _circular_ references
> > between DOM elements and JavaScript objects (you don't have any
> > circular references, but you've broken all refs from JavaScript->DOM,
> > which is a good thing to do). At that point, it's up to the JavaScript
> > implementation when (and whether) to actually reclaim the memory. Some
> > are more aggressive than others, and some are more effective than
> > others.
>
> > Your actual quoted code ends up being very nearly a no-op, which I'm
> > guessing is for testing purposes. It creates 2,000 divs and pushes
> > them on an array (and another div it puts in a property) but never
> > adds them to the document. It then removes the references to them from
> > the array and releases the array (and clears the property). Assuming
> > this code:
>
> >     var t = new TestClass();
>
> > ...by the time the line above is complete, the only remaining memory
> > references I see are the instance itself (`t` above) and the fact that
> > `t` has a property called `options` (which has the value null). If you
> > uncomment the `delete this.options;` line, then even the `options`
> > property that will be gone.
>
> > I took your code and put it (sans alerts) in a page that created 20
> > TestClass objects every 250ms and then threw them away. Using Chrome's
> > excellent about:memory page, I was able to see that the memory does
> > (eventually) get reclaimed by Chrome, Firefox, and Opera on Linux, IE6
> > on Windows 2000, and IE8 on Windows 7. They were wildly different
> > about when they did it. Chrome started at using 12k for the page,
> > which shot up to 60k almost immediately (certainly on the first 40-60
> > TestClass instances), and then allowed memory use to go up to 85-95k
> > before reclaiming back down to 62-64k and letting it climb again.
> > Firefox 3.6 started at about 50k and allowed use to creep up to 250k
> > before reclaiming back down to ~70k again (rinse, repeat). Opera was
> > the most aggressive about reclaiming the memory, starting at 38k,
> > jumping almost immediately to 57k and then staying there, almost
> > completely steady. On Windows, IE8 started at about 33k and allowed
> > that to grow to about 57-59k before reclaiming back down to 33k again
> > and allowing it to grow. (Wow is IE slow.) Even IE6 on Windows 2000
> > (measured via Task Manager rather than Chrome) reclaimed the memory
> > (occillating between 7k and 25k).
>
> > Then I modified the code to retain the TestClass instances, to test
> > whether the instances were somehow keeping the elements in memory. In
> > all five cases (Chrome, Firefox, and Opera under Linux, IE8 under
> > Windows, and IE6 under Windows), they weren't. The memory use was
> > virtually identical to the first test, which shows that by the time
> > you've done your "destroy", the instances *don't* retain any memory
> > references that prevent cleanup. (The instances themselves will be
> > very small.)
>
> > BTW, you don't need to explicitly null-out the array elements before
> > releasing the array. I've heard people say you do, but it doesn't make
> > any sense from a JavaScript specification perspective (not that that
> > matters, particularly not when you're talking about IE) but this
> > seemed like a good opportunity to test it for myself. Commenting out
> > the loop in `destroy` that nulls out the elements made no difference,
> > not even on IE6. I think it's a myth.
>
> > So that means your `destroy` can consist entirely of this:
>
> >     destroy: function() {
> >         delete this.options;
> >     }
>
> > ...since you're keeping everything on the `options` object.
>
> > Here are the test files:http://pastie.org/1240577-the basic counter 
> > testhttp://pastie.org/1240579-keep the instances 
> > testhttp://pastie.org/1240582-don't null out array entries 
> > testhttp://pastie.org/1240613-using the one-liner `destroy` above
>
> > HTH,
> > --
> > T.J. Crowder
> > Independent Software Engineer
> > tj / crowder software / com
> > www / crowder software / com
>
> > On Oct 22, 10:52 am, jose maria Cano <josemaria.c...@gmail.com> wrote:
>
> > > Hi guys,
> > > I have a big problem in my application, when I create a global class
> > > object is impossible for me to release the memory and I'm having
> > > memory leaks.
>
> > > I've made a small class as example.
>
> > > var TestClass = Class.create({
>
> > >     initialize: function() {
> > >         this.options = {
> > >             vari: '',
> > >             array: '',
> > >             testDiv: ''
> > >         };
> > >         this.addElement();
> > >     },
> > >     addElement: function(element) {
> > >         var a = 0;
> > >         var arrayDivs = [];
> > >         alert('before create element');
> > >         for (var i = 0; i < 2000; i++) {
> > >             var div = new Element('div');
> > >             div.innerHTML = 'test' + i;
> > >             arrayDivs.push(div);
> > >         }
> > >         alert('after create element');
> > >         this.options.vari = 'pepe';
> > >         this.options.array = arrayDivs;
> > >         this.options.testDiv = new Element('div', { 'id':
> > > 'testdivPepe' });
> > >         this.destroy();
> > >     },
> > >     destroy: function() {
> > >         alert('before destroy');
> > >         for (var i = 0; i < this.options.array.length; i++) {
> > >             this.options.array[i] = null;
> > >             //this.options.array.pop();
> > >         }
> > >         //this.options.array.splice(0, this.options.array.length);
> > >         this.options.testDiv = null;
> > >         this.options.vari = null;
> > >         this.options.array = null;
> > >         this.options = null;
> > >         //delete this.options.array;
> > >         //delete this.options.testDiv;
> > >         //delete this.options.vari;
> > >         //delete this.options;
> > >         alert('after destroy');
> > >     }
>
> > > });
>
> > > I've tryed the delete, put the variable to null, to undefined, also
> > > remove() for the html and no way to release the memory.
>
> > > I really need some help here. can you give a hand here?
>
> > > Kr, Jose

-- 
You received this message because you are subscribed to the Google Groups 
"Prototype & script.aculo.us" group.
To post to this group, send email to prototype-scriptacul...@googlegroups.com.
To unsubscribe from this group, send email to 
prototype-scriptaculous+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/prototype-scriptaculous?hl=en.

Reply via email to