The old-fashioned way

2005-09-06 21:50:00

My new co-worker Bobby (congrats, man!!) just sent me an e-mail asking about my last post. He wanted to know what tools are available to find memory leaks in IE.

Unfortunately, I don't know of any tool to find stuff like that. (I'd love to know if there are any.) That's one of the many irritations with IE, that there're no tools for developing JavaScript. My need for tools is pretty modest, too. The Moz/Firefox JavaScript console is all I really need -- just something to tell me what's fucked up, and where. IE doesn't even have that. And that's kind of piling on, because stuff breaks way more often in IE.

You can see the leak in progress using the Windows Task Manager, and just looking at how much memory exporer.exe is using in the Processes tab. Each time I created a new event in the Scooby prototype, the memory usage would go up, and it would never get released -- even if I left or reloaded the page. On my little XP laptop, IE initially takes up a little over 16 megs of memory, and I think at one point I had IE up over 80 megs with that leak.

I had to find the leak the old-fashioned way -- by reducing the called code to a smaller and smaller set until I could isolate the piece that was responsible. It was complicated by the fact that I'm trying to use that newfangled hash-style syntax in my code, and I wasn't sure what actually constitutes a closure in some cases.

Fortunately, I tend not to link from DOM objects to my JavaScript objects. Rarely I might create a script object property that points to a DOM node -- but as long as you don't do the reverse at the same time, you won't create the circular reference that sets up the leak. When you destroy the object, it can all get garbage-collected.

I'm really glad I thought to start testing for leaks early on in the process -- think about how evil it'd be trying to sort through all the reams and reams of UI code looking for a leak source. Makes me kind of queasy. So now, I guess any large changes or additions will require IE memleak testing. That's going to be a real pain in the ass, but I guess the alternative is much worse.


This is the blog for Matthew Eernisse. I currently work at Yammer as a developer, working mostly with JavaScript. All opinions expressed here are my own, not my employer's.


Previous posts

All previous posts ยป

This blog is a GeddyJS application.