Wow. Thanks for all the excellent feedback on Drip. It was really just a tool that I needed for myself, but I’m glad that it may prove useful for others as well.
There were a lot of comments, both here and on Slashdot, so I’m going to try to put as many of my thoughts and responses as possible in this post. As such, it may be a bit of a grab-bag.
Exacerbating the problem
The first point I want to make is in response to one or two comments here, and many on Slashdot: That is, that I am not particularly concerned about whether or not I am exacerbating the problem by helping developers to “work around” IE’s issues. Don’t get me wrong; I find it just as unfortunate as everyone else that these problems exist in the first place. It is truly awful that developers using such a high-level tool as a web browser have to take memory allocation issues into account. Particularly given the fact that they’re not really given the tools to effectively deal with them (window.CollectGarbage() doesn’t count, since it won’t really fix the problem).
Anyone who’s spent a significant amount of time developing software has to realize that they will always be dealing with inadequacies of their tools and platforms. This has always been the case. It doesn’t mean that vendors shouldn’t fix their mistakes, but it does mean that you can’t usually bitch at your customers for their choice of platform. If you are going to make software development your profession, then you must generally accept this responsibility. Certainly there are cases where you can dictate the details of the client’s platform, but this is not the case for most vendors.
I also want to point out two things about this specific problem. First, IE’s memory leak issues stem largely from the underlying model that allows scripting languages to interface with native COM objects (that is, making all objects accessible to scripting languages COM objects deriving from IDispatch). While imperfect, this model is also quite efficient – and given that it was developed in the mid-90’s, not an unreasonable compromise at the time. The second point I want to make is that IE is not the only browser with this problem. Mozilla had fairly severe memory leak issues until recently, and I’ve been told that Safari does as well. So let’s not use this as an excuse to jump all over Microsoft.
When do leaks matter?
This is another point that I think bears some discussion. If you’ve spent a little time pointing Drip at existing sites, you’ve probably found that most sites exhibit no issues at all. This is simply because most sites simply don’t use enough complex DHTML (with complex object graphs and the like) to create the specific sort of circular references that cause leaks. Most sites that do have a few leaks seem to be of PARAM objects passed to Java and/or Flash components. I’ve gotten mixed reports on when this happens, and when it causes a significant leak, so the jury’s still out on whether this matters.
On the other hand, I saw one comment to the effect that Google Maps leaks a lot of elements. This is exactly the sort of application that is in danger of leaking enough to matter. If you look at the Maps code, you’ll discover that they’ve done an excellent job of abstracting the components that comprise the application, and it’s quite easy to follow (if you de-obfuscate it, anyway). And I believe that the fact that it leaks so much is actually an indication that its developers have done a good job. The problem is that the very abstractions that make a code base of that size manageable make it really easy to create leaks. Because there are a lot of references among all of its objects, and most DOM elements are wrapped in one way or another, even a single leak can cause the entire reference graph to leak. Nasty, huh?
How do I fix leaks?
This is a pretty complex question. So I’ve decided to punt this to a forthcoming post. There are a lot of resources out there on this subject, but I hope to gather as much of it as possible into one post so that I can provide a reasonable framework for finding and dealing with them.
I’ve gotten a lot of helpful suggestions and a couple of bug reports. What I would like to do now is to list all of the fixes and enhancements that I can think of, and solicit advice on how to prioritize them. Once I’ve had another pass at the code, I will release the source as well so that you can all help maintain it! This is my current list:
- Deal with deeply nested frames. This is a real issue for a lot of sites – apparently Drip only hooks one level of nested frames, but fails to hook deeper windows.
- Hook the cloneNode() method. This is simply an oversight on my part, but it’s necessary to catch all possible leaks.
- Resizable window. This was just me being lazy. I’ve gotten really used to constraint-based layout in the Java world, and to be honest, I just didn’t want to deal with doing this by hand in MFC.
- Sorted and expandable element properties. ‘Nuff said.
- Hook new windows (via window.open). I think this is feasible, and will do my best.
- Anything else you guys can think of!