I have noticed that the memory of the browser starts increasing whilst I am in a form (this is noticeable from the task manager). In IE 9, this goes easily over 500MB after
There are many considerations to keep in mind when you write code that references DOM elements. But it all basically boils down to a couple of simple points -
a. Within your local functions always clear the reference
var menu = $('body #menu');
// do something with menu
.
.
.
menu = null;
b. Never store references as part of element data .data()
c. Try not to use DOM references inside closures/inline handlers, instead pass identifiers
function attachClick(){
var someDiv = $('#someDiv');
someDiv.click(function(){
var a = someDiv....;
//Wrong. Instead of doing this..
});
someDiv.click(function(){
var a = $('#someDiv');
//Pass the identifier/selector and then use it to find the element
});
var myFunc = function(){
var a = someDiv;
//using a variable from outside scope here - big DON'T!
}
}
Yes, one can argue that searching elements can slow the page down, but the delay is very minimal when compared to the performance hit a huge heap causes esp. in large single page applications. Hence, #3 should be used only after weighing the pros and cons. (It did help significantly in my case)
UPDATE
d. Avoid anonymous functions - Naming your event handlers and local functions will help you a lot while profiling/looking at heap snapshots.
Looks like your code creates many DOM subtrees and keeps references to it from javascript. You need to select an element from a Detached dom tree. According to the snapshot you should select Text element. And look into the retainers tree.
This tree shows you all the paths that keeps the object alive. At least one path, usually the shortest one, will lead you to the window object. If you familiar with the code then you may easily find the object in that path that has to be deleted but it doesn't. There can be many such objects in the path. The object with the smallest distance is more interesting.