4 ms·

JavaScript memory leak patterns

32 points by BudVVeezer 17y ago

cscotta 17y ago
This article is a good description of circular references and memory leaks in JS, a pattern which is especially common in IE6 and one which my coworkers have spent a surprising amount of time combatting. Memory leaks border on a special kind of hypochondria, but once you can prove they exist, they're a bear to track down. The biggest surprise in this article, however, was in the bio: _"He has worked as a part of the OS/2 IBM Web Browser Support Team for the past three years."_ The OS/2 Web Browser was Mozilla-based, with open development happening in the free WarpZilla project. Apparently WarpZilla, a port of Firefox to OS/2, is still going strong as of version 3.5.4 (with prereleases of Fx3.6 and Fx3.7 still available): http://www.mozilla.org/ports/os2/ http://www.mozilla.org/ports/os2/
Plugawy 17y ago
One more way of avoiding memory leaks is event delegation - here's quite good article about it: http://www.sitepoint.com/blogs/2008/07/23/javascript-event-delegation-is-easier-than-you-think/ http://www.sitepoint.com/blogs/2008/07/23/javascript-event-d...
cbetz 17y ago
Please correct me if I am wrong, but shouldn't developers only worry about the issues mentioned in the article on older browsers? (I'm thinking IE6 and earlier). Introducing a leak via circular references would be considered a bug in most modern JS engines, right? A related question: Can someone recommend a good plugin/extension for monitoring the size of a page's javascript memory usage over time?
- mhansen 17y ago
  Chrome's Web Inspector lets you take heap snapshots at different times. It won't give you a graph of memory usage, but it will let you monitor it at different times
- BudVVeezer 17y ago
  I think developers should always try to avoid poor programming practices instead of relying on implementation details of the browser.
  - natrius 17y ago
    Poor programming practices? The code that creates circular references is clearer than the example workarounds. Sacrificing clarity to avoid a problem that doesn't occur in supported browsers doesn't make much sense.
    - BudVVeezer 17y ago
      Failing to call "delete" on a pointer you "new"'ed in C++ is also clearer, and just as incorrect. The ECMAScript spec makes no mention of how memory will be managed for the user. Right or wrong in terms of clarity, it's still a poor practice to assume the browser will behave in a particular way that's not covered by the specification (regardless of how sensible that behavior might be!).

32 points by BudVVeezer 17y ago

This article is a good description of circular references and memory leaks in JS, a pattern which is especially common in IE6 and one which my coworkers have spent a surprising amount of time combatting. Memory leaks border on a special kind of hypochondria, but once you can prove they exist, they're a bear to track down. The biggest surprise in this article, however, was in the bio: _"He has worked as a part of the OS/2 IBM Web Browser Support Team for the past three years."_ The OS/2 Web Browser was Mozilla-based, with open development happening in the free WarpZilla project. Apparently WarpZilla, a port of Firefox to OS/2, is still going strong as of version 3.5.4 (with prereleases of Fx3.6 and Fx3.7 still available): http://www.mozilla.org/ports/os2/ http://www.mozilla.org/ports/os2/

Plugawy 17y ago

One more way of avoiding memory leaks is event delegation - here's quite good article about it: http://www.sitepoint.com/blogs/2008/07/23/javascript-event-delegation-is-easier-than-you-think/ http://www.sitepoint.com/blogs/2008/07/23/javascript-event-d...

cbetz 17y ago

Please correct me if I am wrong, but shouldn't developers only worry about the issues mentioned in the article on older browsers? (I'm thinking IE6 and earlier). Introducing a leak via circular references would be considered a bug in most modern JS engines, right? A related question: Can someone recommend a good plugin/extension for monitoring the size of a page's javascript memory usage over time?

mhansen 17y ago
Chrome's Web Inspector lets you take heap snapshots at different times. It won't give you a graph of memory usage, but it will let you monitor it at different times
BudVVeezer 17y ago
I think developers should always try to avoid poor programming practices instead of relying on implementation details of the browser.
- natrius 17y ago
  Poor programming practices? The code that creates circular references is clearer than the example workarounds. Sacrificing clarity to avoid a problem that doesn't occur in supported browsers doesn't make much sense.
  - BudVVeezer 17y ago
    Failing to call "delete" on a pointer you "new"'ed in C++ is also clearer, and just as incorrect. The ECMAScript spec makes no mention of how memory will be managed for the user. Right or wrong in terms of clarity, it's still a poor practice to assume the browser will behave in a particular way that's not covered by the specification (regardless of how sensible that behavior might be!).