I am given with a project that my seniors worked on, this project is developed keeping in mind that the whole page should never be reloaded. So obviously everything went into ajax. And it has 100's of lines that go something like this.
function iCreateProblems()
{
//some rubbish
document.getElementById('some_rubbish').innerHTML=obj1.responseText;
}
and a typical response text is "<div onClick="handleMe()">some thing stupid</div>";
There are three main div's on the page and everything is repeatedly loaded and reloaded into these div's. Now as far as i understand, this will clearly give away to memory leak, right? So how do i fix this? There are about 8000 lines of code that go in this manner. Is there a way i can fix the memory leak? There are hundreds of handlers that are assigned like this. What do i do now?
-
3What makes you think there will be memory leak? JavaScript is parsed inside the browser and fully managed by it, hard to believe DOM manipulation will cause any leak, no matter how complicated it might look. Are you looking for code optimization instead?user447356– user4473562011年07月24日 11:05:58 +00:00Commented Jul 24, 2011 at 11:05
-
Can you explain the functionality the code tries to provide? You might want to replace it entirely if possible.FK82– FK822011年07月24日 13:14:56 +00:00Commented Jul 24, 2011 at 13:14
-
Also, this might be of interest to you: javascript.crockford.com/memory/leak.html .FK82– FK822011年07月24日 13:20:59 +00:00Commented Jul 24, 2011 at 13:20
2 Answers 2
No, it shouldn't. You do not handle memory directly in js; garbage collectors remove everthing unneeded and you don't need to explicitly delete on divs' contents if you overwrite the content.
3 Comments
<div onclick="func();">something</div> ten thousand times you have no memory leaks. If you modify the "inner" html of every divs, you obtain that (new content), no memory leaks, and the handlers are kept untouched (you are changing the content of the divs); if you, updating the content, need to remove the event handler, then you must do it purposely, it is not "automatic". Anyway, non memory leak, just an handler waiting for events to occurWithout seeing the rest of the code there's no way to tell. Despite what people are saying here, it's very easy to create a memory leak in JS and not notice it. The way JS garbage collectors usually work is by marking variables that are "reachable". Variables become considered "unreachable" when their "mark" is taken off and not reapplied, (which is to say, they're completely unreachable by any of the programmer's functions or scopes). After the mark is removed, they're eventually cleaned up by the garbage collector.
One contrived example of a memory leak would be:
(function() {
var xhr = $.get('http://google.com/');
$('a').click(function() {
console.log('hello');
});
})();
As long as that element exists on the page, with that event listener bound to it, the variable xhr will never be cleaned up by the garbage collector. Even though xhr is never used anywhere in your code, the garbage collector will refuse to clean it up because it is still "reachable" by your event listener.
edit: I should also mention, there is also the possibility of a memory leak occurring from bugs in a poorly written JS engine. (See also: Internet Explorer). Most DOM libraries account for this and make sure to avoid these problems, but it can still happen. For these memory leaks you need to find a workaround for that particular engine.
5 Comments
<a> tag is removed from the DOM, everything can be released. Your scenario is called memory usage. I agree, there may be an unintentionally prolonged and unnecessary usage, but it isn't leaked. Moreover, there are engines that optimise that scenario and don't hold references in the lexical scope to unused variables. In fact, I assume most modern engines would allow xhr to be released straight away.$('a').click() to a setInterval() leaving no access to the id, would you be happy? Also, the fact of the matter is, you can't rely on JS engines to optimize anything in a browser environment. You have to assume the worst.