1

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?

asked Jul 24, 2011 at 10:58
3
  • 3
    What 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? Commented 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. Commented Jul 24, 2011 at 13:14
  • Also, this might be of interest to you: javascript.crockford.com/memory/leak.html . Commented Jul 24, 2011 at 13:20

2 Answers 2

1

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.

answered Jul 24, 2011 at 11:05
Sign up to request clarification or add additional context in comments.

3 Comments

But there are event handlers on all the response texts. What about those event handlers? To my understanding these event handlers are not removed from memory once the data is over written. Isn't that so?
@sasidhar: well, you can remove event handlers (see stackoverflow.com/questions/803936/…), but I doubt it will give any additional page productivity
if you write <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 occur
1

Without 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.

answered Jul 24, 2011 at 12:03

5 Comments

Is your example pure JavaScript?
yes, my example is pure javascript. My code overwrites the innerHTML in the three main div's i mentioned. So doesn't this mean that the eventhandlers to the overwritten elements still exist in the memory?
Your example isn't a memory leak. A leak is a scenario where the allocated memory cannot be released by the program back to the OS, although as soon as the matched <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.
davin, you're right, it's not technically a memory leak. It is an example of a mechanic that could create one though. If I changed the $('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.
-1 because started a general discussion instead of answering the question.

Your Answer

Draft saved
Draft discarded

Sign up or log in

Sign up using Google
Sign up using Email and Password

Post as a guest

Required, but never shown

Post as a guest

Required, but never shown

By clicking "Post Your Answer", you agree to our terms of service and acknowledge you have read our privacy policy.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.