Plugging Internet Explorer's Leaks 480
jgwebber writes "If you're developing DHTML web apps, you probably already know first-hand that Internet Explorer has horrendous memory leak issues. You can't not run on IE, so you've got to find a way to plug those leaks. So I've created a tool to help you find them. So until Microsoft decides to fix its browser architecture (ha!), at least we can keep it from blowing huge amounts of memory."
Pesty Internet Explorer Memory leak ... (Score:2, Informative)
Quick and dirty fix (Score:3, Informative)
2. Right-click anywhere, select New, then Integer. In the dialog prompt that appears, type:
browser.cache.memory.capacity
3. Click OK. Another dialog prompt will appear. This is where you decide how much memory to allocate to Firefox. This depends on how much RAM your computer has, but generally you don't want to allocate too little (under 8MB), but if you allocate too much, you might as well not do this. A good recommended setting is 16MB. If you want 16MB, enter this value into the dialog prompt:
16384
(Why 16384 instead of 16000? Because computers use base-12 counting. Thus 16 megabytes = 16384 bytes. Likewise, if you want to double that and allocate 32MB, you'd enter 32768.)
4. Click OK to close the dialog box, then close all instances of Firefox and restart. If your Firefox still uses the same amount of memory, give it a few minutes and it should slowly clear up. If that fails, try a system reboot.
To be specific... (Score:1, Informative)
The type of garbage collection Internet Explorer uses screws up when you use ActiveX objects (e.g. XMLHttpRequest) or the DOM. More information is available from the comp.lang.javascript FAQ notes [jibbering.com].
Personally, unless I'm writing a web application, I say screw the users that use that substandard browser. Their browser will eat up more and more memory until they crash on some other website. This would have been fixed four years ago if Microsoft hadn't killed Internet Explorer development once they cornered the market.
best plug for it (Score:2, Informative)
vulnerabilities, bad experiences, and poignant advice, people still continue to use it.
The alternatives aint perfect but they are a hell of a lot better.
"Microsoft Internet Explorer 6.x with all vendor patches installed and all vendor workarounds applied, is currently affected by one or more Secunia advisories rated Highly critical"
"Currently, 20 out of 81 Secunia advisories, is marked as "Unpatched" in the Secunia database."
http://secunia.com/product/11/ [secunia.com]
Re:How about firefox? (Score:2, Informative)
Is such an approach also useable for finding firefox leaks?
Doubtful. This is targeted at a very specific memory leak that Internet Explorer is known to have.
As a user (not developer, alas) I'm noticing that it invariably gets sluggish after some period of time, even with few pages open.
Apparently Firefox 1.1 will fix a lot of these memory leaks. You can try out "Deer Park" if you want a preview of Firefox 1.1.
First, is it a problem? (Score:3, Informative)
If you do have accompanying slowdowns, then you have a specific, rare problem. See the other replies you've gotten so far for suggestions.
Re:Quick and dirty fix (Score:1, Informative)
Thus 16 megabytes = 16384 bytes
(ha!)
Mods: If this is informative, you are definitely insane.
NOOB... (Score:1, Informative)
Where does the memory leak to?
RTFA (Score:2, Informative)
Re:Has anyone used firefox? (Score:3, Informative)
Also, it's not on one machine, its on multiple machines running various OSs. The lower you go, the slower gecko gets. On a 533mhz machine (IBM PC 300) with 96Mb ram, firefox (and epiphany, tried both,hoping that epiphany might contain some gecko optimizations) was slower to render some pages while doing nothing else than opera was while compiling software in the background. The slowness is less pronounced on newer hardware, and curiously on windows! But I can still see it very clearly on my home pc (athlon xp 2400+ with 512RAM) if I do something CPU intensive in the background (like having multiple compiles running, downloading a huge file, listening to music at the same time). On an idle computer, you won't really see the difference, but if you have a cpu-monitoring tool running (I h ave kcpuload) you can easily notice that gecko to render the same pages with the same speed as khtml, grabs a lot more of the CPU than the latter. When those resources are scarce, it will be significantly slower than browsers built on other engines (Opera seems to kick ass along with khtml).
Firefox Sucks (Memory) (Score:4, Informative)
Thanks, I'm glad someone pointed this out. My system has been up for many days now and IE and Firefox are both consuming about the same amount (90-something MB).
Re:First, is it a problem? (Score:1, Informative)
Every Slashdot article on Firefox has people talking about this problem. If they design team doesn't know, then they are too far lost to be of any use. I kill Firefox about once a day. I mean kill, not quit. Many times it is far faster to relaunch the program than it is to get it to open a new tab for Google.
The problem isn't while you are doing multiple things with Firefox. That works great. Do those things, leave a bunch of tabs open, and then minimize Firefox. Now do a bunch of file I/O and over an hour or so. When you reopen Firefox it is unusable. After minutes it will draw the screen, then when you click a tab it takes half a minute to draw that one. Try to quit and it takes half a minute to draw the "ok to close all these tabs" dialog. Drives me crazy and I'm sure it sends plenty of people back to IE.
Don't believe me? Fine. Look at all the other people commenting here. Do you really think we are part of some grand conspiracy?
Re:RTFA (Score:3, Informative)
Not exactly.
It detects memory leaks that are due to the two separate garbage collection routines that IE employs for DOM objects on the one hand, and JavaScript objects on the other. The leaks occur when a developer creates a circular reference between a JavaScript object and a DOM object, which is a very easy and natural thing to do.
For example, this creates a memory leak in IE:
someNode.onmouseover = function() { this.style.color = "#f00" };That is "poor" code only in the sense that it trips over IE's DOM/JS circular reference memory leak problem. Other browsers (e.g., Firefox 1.0.4, Safari 1.3+) handle that code with no memory leaks.
So while it may be true that it is possible to write a web page that will cause a given web browser to leak memory, this DOM/JS problem is particularly evil because it occurs not with some obscure, complex, or malicious coding practice, but with one that is very common and natural.
Re:How about firefox? (Score:2, Informative)
Re:How about firefox? (Score:3, Informative)
Bubble bustin' time! Garbage collection doesn't always live up to its reputation. I have seen Java apps leak memory like a sieve. This one project I was working at would start up a production (!) EJB container in the morning, and by 13:00, it would have run out of memory and crashed. I told them to fix their leaks. When they got over arguing that the garbage collector prevents memory leaks and checked it against a memory profiler... they started fixing the memory leaks and the problem was solve.
In any case, I doubt that the garbage collection in the Javascript engines are anywhere near as sophisticated as in Java itself. So I would think it would be easier to leak memory. Anyway Mozilla has a bit of an article on this here [mozilla.org].
great idea (Score:4, Informative)
Why not leave IE to Microsoft; put your effort toward something you can actually fix rather than being an ankle-biting ass.
Re:Proofreading? (Score:1, Informative)