Wednesday, March 7th, 2007

Garbage Collection in IE6

Category: Articles, JavaScript, Performance

Daniel Pupius had the unfortunate “cause to do some investigation into the effects of Internet Explorer’s garbage collection routines on performance” and kindly wrote up his findings:

Eric Lippert posted about the internals of IE’s garbage collector back in September 2003, though he skimmed over the important bits, which were later noted in the comments. The crux of the problem is that IE’s script engine uses allocations to determine when to run the GC; that is after 256 variable allocations, 4096 array slot allocations, or 64kb of strings have been allocated. Not only are allocations a bad indicator of garbage, but these limits are such that any decent sized application is going to make the GC run pretty regularly.

To compound this problem, the running time of the garbage collection routine is dependent on the size of the working set (O(N^2) as described in Lippert’s article, though the results below show a linear relationship). So as your application gets bigger the garbage collection runs slower.

Back in the day this didn’t really matter, but as web applications are getting more complex there is the potential to hit a performance wall. More code being executed means the garbage collector will be run more frequently; and because the applications contain more state on the client; and have larger code bases, the object graph that the garbage collector has to traverse gets bigger.

He tested this with a benchmarking function which creates 5000 object literals with random properties, and then sorts them.

The following results show the mean execution time of the create-and-sort test as O increases for constant P=50 on Firefox 2.0 (red) and IE6 (blue) on the same computer.

What can you do about this?

  • a) Ask your IE 6 users to patch up
  • b) Ask your IE 6 users to upgrade to IE 7
  • c) Ask your IE 6 users to change browser
  • d) Optimize your application by reducing code size and finding the balancing point between improved performance from keeping state local and keeping your working set to a manageable size. Always explicitly dispose objects when they are no longer needed by removing event handlers and dereferencing properties.

Posted by Dion Almaer at 1:03 am

3.8 rating from 38 votes


Comments feed TrackBack URI

It will be interesting to see also IE7 on this chart!

Comment by ajaxus — March 7, 2007

e) Ask your IE users how many prove we need to give them before they’ll run away definitely from every IE

Comment by Andrea Giammarchi — March 7, 2007

@Andrea: Definitely, option [e] is the best!


Comment by Valery Silaev — March 7, 2007

Correct me if I’m wrong, however this test does seem skewed (as Daniel notes in his post) towards exploiting the flaws in IE’s GC algorithm. Since Firefox doesn’t have a GC algorithm with the restrictions described in Eric and Daniel’s respective blog posts, I’m not surprised by this result. I don’t think it necessarily leads to the conclusion that the GC algorithm in FF is “better”, but merely that this type of behavior in a web app’s script could lead to undesired behavior in IE.

I am also puzzled by the inclusion of the sort function call in between the start and endpoints of the benchmark timing – since, aside from the variable allocation within the sort function, nothing about sort itself _should_ trigger browser GC. I’d be a little concerned that the O(n^2) performance could be attributed to a poor implementation of a sort function in IE (very easy to get O(n^2) performance characteristics from a poorly-written sort). I’d be interested if Daniel could comment and/or follow-up with another chart of results without the sort function included.

Comment by Peter Mularien — March 7, 2007

Some time ago I’ve created small application that uses Y! Maps API (

Check it in IE and FF — even perceptive application performance is much better in FF. Debugging shows that certain algorithms works 7 to 10 times slower in IE, even trivial array/string manipulations — and there is no intensive DOM manipulations with HTML tables that literally sets IE on knees.

I hope that you will not consider this as a “skewed test”


Comment by Valery Silaev — March 7, 2007

Knowing Dan well, I would hazard a guess that he showed the performance against FF not as a “we’re bashing IE and showing how much more superior FF is” but more as a “here’s what happens with IE, and just for comparison sake, here’s the equivilent in FF”. I’d also hazard a guess that he’s be willing to use any other browser (i.e. opera or safari) as part of the chart. I’d also be wiling to wager that he used sort only because it is an O(n^2) operation; any other O(n^2) op will probably show the same results.

Comment by Tom Trenka — March 7, 2007

> Correct me if I’m wrong, however this test does seem skewed

Of course it is since the goal of the test is to expose and understand the IE bug, and show the impact it can have on applications (plus it’s not like the bug is only triggered by an obscure corner-case you’re unlikely to run in, more like the opposite), in order to get creators of JS applications to:
1. Be aware of the issue and watch for it
2. Try to change their practices in order to reduce the chances of encountering the issue.

Comment by Masklinn — March 7, 2007

IE is a festering pile.

I just spent 30 hours rewriting our new website because of IE’s box model problems…

Comment by Karl — March 7, 2007

I have done extensive tests on this issue as well. It is indeed true that the IE 6 GC algorithm is O(n^2) with object creation because the GC algorithm does collection with a constant number of new slot creation. It is quite straightforward to deduce that O(n^2) results from IE’s description of the algorithm. This is a major flaw. By doing collection less frequently as live object graphs grow, O(n) (or at least O(n log n)) time overall GC with object creation can be achieved as is the case with FF and IE7.

Comment by Kris Zyp — March 7, 2007

The create-and-sort test was simply uses as a relatively intensive operation to demonstrates the slow down in JavaScript performance. It uses a custom sorting function which requires object lookups. The create-and-sort always runs a set number of times, 5000, so in a perfect environment it’s runtime shouldn’t vary.

You get the same results with a number of test functions. For example, looping and pushing strings to an array, evaluating a large JSON string, basically anything that causes the allocations to be hit.

The FF results are provided as a comparison, I just didn’t spend the time to fully benchmark other browsers. Increasing the allocations using the hotfix will give you a graph comparable to FF, IE7 is also the same.

Comment by Dan Pupius — March 7, 2007

Sorry, that wasn’t clear. Let me clarify: the runtime of the test function is irrelevant since it is always creating and sorting 5000 objects. The point is that the number of in-scope objects that the GC has to traverse cause the slowdown, even though the test doesn’t ever touch them directly.

Comment by Dan Pupius — March 7, 2007

I had a big project hit “the wall” in IE 6 pretty hard not too long ago – the issue seemed to stem from the number of objects we were creating, assigning DOM references and event handlers on those references via JS. As more objects and references were created, the browser started taking increasing (on a more-than-linear basis) amounts of time looping through node collections, parsing data and so on. This was an IE-only issue, so for IE, a rather simple fix was implemented: Each “old” page of objects is destroyed, events and DOM references are released as a new page is loaded in (via XHR), and the browser remains snappy.

Comment by Scott Schiller — March 7, 2007

Is this a nice trivia point, or did Microsoft never put this out via Automatic Updates? More than a third of people have updated to IE7 worldwide, and I would imagine most IE6 users have automatic updates on (and if they don’t, this likely isn’t their biggest problem).

How about the reverse? IE7 vs. Netscape Navigator?

Comment by Steven Roussey — March 7, 2007

The hotfix isn’t available as an automatic updates and still requires tweaking the hex value of registry settings.

Comment by Dan Pupius — March 7, 2007

Leave a comment

You must be logged in to post a comment.