IE6 Garbage Collection and general IE6 slowness problems

[timothytoe]

Microsoft fixed some garbage collection problems in IE6 almost a year
ago. I'm trying to figure out if many users of IE6 are unpatched and
still have the old buggier JScript in them.

I have a rather large ECMAScript app that is speedy enough in just
about every browser but IE6. Some people tell me just to forget IE6,
but it still seems to have significant share at www.w3schools.com. And
anecdotally, the place my brother works (incredibly) still mandates
IE6 on company computers.

I have the feeling that I can't count on people having upgraded their
IE6s to the better GC JScript. If they were the upgrading type, seems
like they'd be using IE7 or another browser rather than IE6.

I'm sure it's uncool to tell IE6 users to use one of the browsers that
I wish they would use (but see the next paragraph for my thoughts on
this), so I'm looking for specifics on what I should and should not be
doing for IE6's sake, especially to ease or head-off garbage
collection problems. Do I explicit tear down objects and arrays at the
end of functions? Do I avoid closures? Anything else?

Uncool though it may be, I am tempted to throw IE6 users some kind of
warning that they're in for a long wait if they try something
especially ambitious. I could then offer them a way to speed things
up, like offering an Adobe AIR version and giving benchmarks of
different PC browsers performing the task. Thoughts on that tactic?

 

[Peter Michaux]

Is your app slow from the word Go, or does it degrade over time?

Please quote enough of the post to which you are replying so that your
post is stand alone. Not all Usenet participants are using a threaded
reader.

Peter

 

[timothytoe]

Is your app slow from the word Go, or does it degrade over time?

I have problems on both fronts in IE6. From the get go and
degradation.

The user has control over the number of objects operated on and IE6 is
much worse than IE7 when the number of objects increases. I've
considered reducing the capabilities (max objects) when I detect a
slow browser, but that seems really cheesy, and I'd rather just get
the code as fast and clean as I can. For large numbers of objects, the
newest browsers do all their calculations and statistics in seconds.
IE6 is crazy slow.

 

[Bart Van der Donck]

I have problems on both fronts in IE6. From the get go and
degradation.

The user has control over the number of objects operated on and IE6 is
much worse than IE7 when the number of objects increases. I've
considered reducing the capabilities (max objects) when I detect a
slow browser, but that seems really cheesy, and I'd rather just get
the code as fast and clean as I can. For large numbers of objects, the
newest browsers do all their calculations and statistics in seconds.
IE6 is crazy slow.

Although it's generally not advised, maybe this is one of the cases
where 'CollectGarbage()' could help.

http://groups.google.com/group/comp.lang.javascript/msg/a2cb27b343cd6da5
http://groups.google.com/group/comp.lang.javascript/msg/fe3c7c11f20ad185

 

[VK]

I have problems on both fronts in IE6. From the get go and
degradation.

The user has control over the number of objects operated on and IE6 is
much worse than IE7 when the number of objects increases. I've
considered reducing the capabilities (max objects) when I detect a
slow browser, but that seems really cheesy, and I'd rather just get
the code as fast and clean as I can. For large numbers of objects, the
newest browsers do all their calculations and statistics in seconds.
IE6 is crazy slow.

The garbage collection mechanics of the JScript engine is explained by
Eric Lippert at
http://blogs.msdn.com/ericlippert/archive/2003/09/17/53038.aspx

Even more valuable details can be found in the blog comments,
including the upcoming changes of gc algorithms in IE8.

Without analyzing the actual application code you are having problems
with, it is hardly possible to say anything more practical.