How does JavaScript memory work in browsers?

Question

When building advanced JS-interfaces and games I've found that I have to dig deeper in to how browsers handles memory for JS. My experience with memory and JavaScript is that the memory gets glogged (and makes animations and calculation slow/lagging ) when:

• There is alot of JS-generated content on the page
• There is alot of graphics (img-elements) on the page?

I have therefore concluded that if I want to keep my memory fresh I should include as much HTML code as possible from the beginning of the document as it will be cached and not kept in memory. And off course remove all currently not used elements.

Does anyone have any more info on this? Resources? Links?

Answer 1

For starters. All HTML, whether it is "include from the beginning" or not, is kept in memory. Most likely also all image content for the current page. At a bare minimum, everything that you see on-screen at any given time is kept in memory at that time.

Answer 2

It tends to depend more on what you're doing with it to be honest. A lot of graphics aren't going to do squat to javascript if you aren't interacting with them but if you've got an enormous page filled with different elements and you're searching the entire document for a single element then that's a different thing entirely.

I've had problems doing things like adding massive amounts of events to pages. Running too many loops in a page and too many timers.

If javascript performance is an issue and you're planning on doing intensive javascript, you might want to look at webworkers. Here's a few more links on webworkers:

• John Resig
• The spec

Answer 3

Some things to keep in mind:

• IE gets killed by DOM complexity. The more elements are part of the page, the slower it gets. I've seen pages slow down noticeably with as little as 3000 elements on them (if you have a grid with 10 columns and 100 rows, that's 1000 elements right there). The right approach is typically to unload hidden parts from the DOM (detach them)
• IE also has a long history of not correctly freeing HTML elements if they have javascript handlers attached. If you have a long-lived page that's often refreshed, read up on IE memory leaks, and how to work around those issues.
• All browsers store images uncompressed in memory. So, if you're preloading a gazillion large images in the background, that's generally a bad idea.
• Updating DOM properties will cause page reflows, which on complex pages can take a long time. Sometimes even fetching DOM properties (e.g. offsetHeight) will be very very slow.

Generally, javascript itself is not a performance bottleneck. What kills it is the interaction with the DOM. Code that doesn't touch the DOM rarely has performance issues. There are only rules of thumb here: interact with the DOM as rarely as possible, keep DOM complexity as low as possible, avoid repeated page reflows.