Wednesday, March 7th, 2007p>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.