[Proto-Scripty] Deleting a class object releasing the memory.
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.
[Proto-Scripty] Re: Anchor button triggers window.onbeforeunload in IE
Hi,
See the documentation for `Event.observe`[1] (which is what you're
calling indirectly from the `Element#observe` function), specifically
the Preventing the Default Event Action and Bubbling part, and the
`Event` object[2]: You don't return false to cancel the `click` event,
you use the `Event#preventDefault` function (which is a standard DOM
function[3] that Prototype ensures is present even on implementations
that lack it) or, more likely, `Event#stop`[4] which both prevents the
default action and stops the event bubbling.
[1] http://api.prototypejs.org/dom/event/observe/
[2] http://api.prototypejs.org/dom/event/
[3]
http://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-Event-preventDefault
[4] http://api.prototypejs.org/dom/event/stop/
HTH,
--
T.J. Crowder
Independent Software Engineer
tj / crowder software / com
www / crowder software / com
On Oct 22, 2:41 am, JoJo tokyot...@gmail.com wrote:
I use anchors to call javascript functions. Usually, I do this:
a href=javascript:void(0) onclick=someFunc(); return false;
call the function
/a
This works fine in all browsers. Window.onbeforeunload is never
triggered because the ONCLICK returns false, and thus the HREF if not
executed. When HREF is not executed, the browser does not believe that
the window in unloading. Now, I'm trying to create a dynamic anchor to
accomplish the same thing. It looks nearly identical to the HTML
anchor, but now it's triggering window.onbeforeunload in IE8. How do I
not trigger it?
dynamicAnchor = new Element(
'a', {
href: 'javascript:void(0)',
}
).observe(
'click',
function(parameter) {
return function() {
window.status = parameter;
return false;
}
}(localVariable)
);
--
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.
[Proto-Scripty] Re: Deleting a class object releasing the memory.
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 test
http://pastie.org/1240579 - keep the instances test
http://pastie.org/1240582 - don't null out array entries test
http://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 =
Re: [Proto-Scripty] Re: mousedown observer cancels button click?
On Oct 21, 2010, at 6:32 PM, T.J. Crowder wrote:
Instead, I'd do it in the obvious place: The form submit event:
http://jsbin.com/aniro4/3 Or you could do it on the `click` event of
the button: http://jsbin.com/aniro4/4 (I wouldn't use `mouseup` on the
button, in case there are things the user can do that won't trigger
the click but *will* trigger `mouseup` -- like pressing down
elsewhere, the moving the mouse onto the button and releasing the
mouse button. Let's defer to the UA about when the user's actually
clicked the button.)
Thanks, TJ, that's about what I had figured. But I have had massive
problems with hooking the submit event and modifying the DOM. In about
half the cases I've tried this, I end up with one or another browser
just not updating the DOM after the submit event has fired. The page
sits there with its tongue hanging out, and never updates.
I have tried stopping the submit, then updating the page, then firing
this.up('form').submit() or similar, which works, but can then
introduce other problems I don't like to fix, like not passing along
the clicked submit button, for cases where I include a submit button
named delete, and key the form handler's action off of that element's
presence at the server.
Everything's a trade-off.
Walter
--
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.
[Proto-Scripty] Re: Deleting a class object releasing the memory.
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
[Proto-Scripty] Re: Deleting a class object releasing the memory.
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
[Proto-Scripty] Re: mousedown observer cancels button click?
Hi,
Yeah, changes to the DOM that's being torn down are probably pretty
low priority.
If you really, really want to do this, I'd probably do a lib that:
1. Dynamically replaces the type='submit' buttons with type='button'
buttons.
2. Watches for clicks on them.
3. In the click handler, do your form validation (since you won't get
a submit event), and if it passes add a hidden element to the form
using the button's value, show your covering div, and set up the
delayed submit of the form.
...then reuse it. :-)
-- T.J.
On Oct 22, 2:32 pm, Walter Lee Davis wa...@wdstudio.com wrote:
On Oct 21, 2010, at 6:32 PM, T.J. Crowder wrote:
Instead, I'd do it in the obvious place: The form submit event:
http://jsbin.com/aniro4/3Or you could do it on the `click` event of
the button:http://jsbin.com/aniro4/4(I wouldn't use `mouseup` on the
button, in case there are things the user can do that won't trigger
the click but *will* trigger `mouseup` -- like pressing down
elsewhere, the moving the mouse onto the button and releasing the
mouse button. Let's defer to the UA about when the user's actually
clicked the button.)
Thanks, TJ, that's about what I had figured. But I have had massive
problems with hooking the submit event and modifying the DOM. In about
half the cases I've tried this, I end up with one or another browser
just not updating the DOM after the submit event has fired. The page
sits there with its tongue hanging out, and never updates.
I have tried stopping the submit, then updating the page, then firing
this.up('form').submit() or similar, which works, but can then
introduce other problems I don't like to fix, like not passing along
the clicked submit button, for cases where I include a submit button
named delete, and key the form handler's action off of that element's
presence at the server.
Everything's a trade-off.
Walter
--
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.
[Proto-Scripty] Re: clear prototype hash
It looks like TJ got you an answer, but do you also realize that there
is a typo in the snippet you posted here?
hashBrown.length=0 and hashBrown.clear().
***hashBown***.each(function(key) {
hashBrown.unset(key);
});
hashBown - hashBrown (missing 'r')
-K
On Oct 20, 10:39 pm, chrysanthe m chrysant...@gmail.com wrote:
Hello
How do I clear a prototype hash? I have finally tried and failed with below
after trying hashBrown.length=0 and hashBrown.clear().
hashBown.each(function(key) {
hashBrown.unset(key);
});
--
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.
[Proto-Scripty] Prototype 1.7 Production (when it is out) and Script.aculo.us
Hey Folks - So I have a situation that I think a lot of us are in that I want to see if I can plan for. So, IE9 is probably going to be released before the production version of Scripty2. And I have a few (in production) web apps that run on Script.aculo.us. Prototype is adding in IE9 support in 1.7 (which I assume will be released before IE9). So the situation is you/me/whomever doesn't want to run beta (scripty2) code on a production site. And, unfortunately, it is an absolute must to support IE9 when it comes out. However, I don't know if the Prototype team is making sure their new code works with the in production script.aculo.us. Even testing a great deal isn't going to really reveal this because there could be issues that only show themselves in one particular version of a particular browser. The alternative is to force IE to behave as IE8 for the time being (but that isn't ideal because I have some canvas code and I would like excanvas to slowly be used less because it is WAY slow). Anyhow, being this is going to be a big issue for, well, everyone who is using script.aculo.us for anything serious I thought I would ask. -- 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.
[Proto-Scripty] Re: Anchor button triggers window.onbeforeunload in IE
Thanks T.J.
The solution is:
dynamicAnchor = new Element(
'a', {
href: 'javascript:void(0)'
}
).observe(
'click',
function(parameter) {
return function(event) {
window.status = parameter;
Event.stop(event);
}
}(localVariable)
);
On Oct 22, 4:39 am, T.J. Crowder t...@crowdersoftware.com wrote:
Hi,
See the documentation for `Event.observe`[1] (which is what you're
calling indirectly from the `Element#observe` function), specifically
the Preventing the Default Event Action and Bubbling part, and the
`Event` object[2]: You don't return false to cancel the `click` event,
you use the `Event#preventDefault` function (which is a standard DOM
function[3] that Prototype ensures is present even on implementations
that lack it) or, more likely, `Event#stop`[4] which both prevents the
default action and stops the event bubbling.
[1]http://api.prototypejs.org/dom/event/observe/
[2]http://api.prototypejs.org/dom/event/
[3]http://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-Event-prev...
[4]http://api.prototypejs.org/dom/event/stop/
HTH,
--
T.J. Crowder
Independent Software Engineer
tj / crowder software / com
www / crowder software / com
On Oct 22, 2:41 am, JoJo tokyot...@gmail.com wrote:
I use anchors to call javascript functions. Usually, I do this:
a href=javascript:void(0) onclick=someFunc(); return false;
call the function
/a
This works fine in all browsers. Window.onbeforeunload is never
triggered because the ONCLICK returns false, and thus the HREF if not
executed. When HREF is not executed, the browser does not believe that
the window in unloading. Now, I'm trying to create a dynamic anchor to
accomplish the same thing. It looks nearly identical to the HTML
anchor, but now it's triggering window.onbeforeunload in IE8. How do I
not trigger it?
dynamicAnchor = new Element(
'a', {
href: 'javascript:void(0)',
}
).observe(
'click',
function(parameter) {
return function() {
window.status = parameter;
return false;
}
}(localVariable)
);
--
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.
