Separate names with a comma.
Discussion in 'General Software' started by BillLeeLee, Dec 18, 2005.
over 1.2 GB used. ...Impressive, huh? They really gotta implement a fix for the whole images thing.
JEEZ! most i ever got was 83 something megs.
Is your screen shot that grainy? OR is that my eyes?
Sorry, it's a result of me making it a GIF in MSPaint.
Oh it's nothing i just had FF grain out like that on me today earlier and I was wondering if it was happening again.
I thought mine getting up to 400 MB was impressive. I stand corrected!
wow, thats terrible, like what is firefox running there? I bet you have like 20 tabs open and downloading a bunch of crap at the same time through it.
and yes, thats also terrible, your window shot is grainy. wtf?
Actually, that memory usage resulted from one tab, and I surfed page 14 - 17 of the wallpaper thread in the anime section (40 posts per page). There were probably 300+ images in those three pages, accounting for about 100 MB of downloads.
And I've already explained my screenshot - it's due to the GIF format.
I really shoulda checked my memory usage b4 closing this..
probably looked a bit high.
What did you do, accidentally open all the Live Bookmarks in separate tabs like 10x?
I'm now using this build of Firefox from http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2005-12-21-06-trunk/
(latest trunk for today)
It's working nicely and has been stable, so far.
You might want to *test* it out to see if your problem is fixed with this build.
I have been back using opera the last couple of days....and the memory use there is worse for me than firefox. I won't be complaining about Firefox mem leaks anymore.
wow, that is crazy stuff, i will stick with opera for now
lol its funny, I was just going to say, thats why you get Opera
Nevermind on the build. I found a sore spot. Image maps with application/xhtml+xml are broken. Oh well, to be expected.
The "Firefox leaks memory like crazy look at this!" posts are starting to grate a little.
Folks, there is a very simple solution to this. Go to about:config, right-click, create a new boolean value, type config.trim_on_minimize in the first window, and select true in the second.
Now Firefox will release nearly every MB of RAM it uses when you minimize it. After bringing Firefox back into focus, it will only use the bare minimum of RAM it needs at that time. What happens after FF starts sucking up another 200MB of RAM? Minimize again. It's like magic, except not!
this is much faster than 1.5 its ridicilous.
with ~25 tabs regularly open in opera i dont go over 200mb ram usage.
but good lord, 1.25gb is crazy.
Yeh, it's super fast compared to 1.5.
Try the latest Firefox mozilla-1.8 branch builds for something more stable
errr.. I mean quoted and strange word searchable so I can easily find it again to dump into all these damn threads
(got tired of having to assemble queries to find your instruction in here or on the web)
Opera does this automatically. We've been told that this is a standard windows feature.
However, we've been told that it doesn't really free memory. It just dumps it to the page file and when the browser needs it back, there's a performance hit because it's grabbing things from disk instead of memory.
Perhap Firefox does something special and really releases unused memory. Something you might want to check to make sure.
It seems that the memory usage behaves differently in both Linux and Windows. I went to the same thread that caused my memory usage to balloon dramatically in Windows, this time under my Linux install, and the memory usage of FFox didn't jump from its level of 100 MB (I had 8 tabs open), but rather it caused my Xorg server's memory usage to increase to 25% of system RAM (which for me is roughly 750 MB). However, I cleared that tab (not exiting firefox) and memory usage went back to normal, something that I did not observe after closing the tab in Windows.
I didn't really intend for this to be a "OMG Firefox uses so much memory, leaks are insane" post. Memory usage in Firefox probably wouldn't blow up to such a level were it not for the way it handles images - that is, Firefox doesn't really free up the images from memory when you close a tab (at least in Windows).
Without the tweak config.trim_on_minimize -
With the tweak config.trim_on_minimize -
It may very well be a standard Windows feature, but Firefox still won't release memory on minimization unless you enable the tweak. As for Opera... that's nice, but completely irrelevant to Firefox.
Your source on this? The behavior I've observed after enabling config.trim_on_minimize doesn't line up with the activity you're describing.
Is this a bug in the Mac version of Firefox also?
A few sources on the subject:
Quote from the bug report on that page:
Config.trim_on_minimize = false (default in Firefox 1.5):
Turns off trimming of the working set when minimizing so parts of Firefox aren't unnecessarily swap to disk. This is a patch to make Firefox appear faster when restoring after being minimized for a long time. Normally, Firefox would have to swap in and reallocate a bunch of memory when restoring. This setting can cause Firefox to hold on to memory longer, but apparently this solved a major problem so they decided to enable it by default. (And some people don't like it)
Config.trim_on_minimize = true:
Makes Firefox 1.5 behave like a normal windows app where minimizing aggressively swaps things to disk. This is the same thing that Opera and other windows apps do. It frees memory, but there's a performance hit when you restore because it needs to grab it all back. This is the "let windows do it's work" option. To change this option, you have to add it to about:config and restart. It's a bool type. (true/false)
Anyway, that's what the setting does. Now if Firefox is leaking memory and this clears things up a bit, that's cool, but not actually what the setting is for. The setting just makes Firefox behave like it used to (which is like other apps like Opera).
For Opera sources, see http://my.opera.com/community/forums/findpost.pl?id=956566 for one of them. Search the forums for more of the same.
Not sure if the setting is *needed* for other OSs or not. I think all OS versions of Firefox 1.5 have memory problems though. The branch build I mentioned earlier works great so far.
If you have not yet, you should turn on the "peak memory usage", and "virtual memory size" columns in the task manager and keep an eye on the VM status, but really compare the peak memory after minimizing with the trim setting on true and the trim setting on false. You can then see what is and isn't going on.
Looks like it's definitely a swap file dump--which is fine with me, as it drastically frees up physical memory, which is better than nothing, and makes config.trim_on_minimize a useful tweak. Still makes me wish the FF developers would stop being so cavalier about system memory usage, though.
Turns out the image map problems in the trunk builds are not problems at all. They just changed the handling of the usemap attribute. The usemap attribute value is of type URI in *all* situations now regardless of mime type and regardless of doctype and must contain the #; even in XHTML 1.1.
The XHTML 1.1 doctype is once again considered to be in error when it comes to the usemap attribute and you should ignore the XHTML 1.1 doctype specs and ignore the w3c validator errors when it comes to the usemap attribute. The W3C hasn't updated the specs on their site to reflect the changes.
I gave up on Firefox for the time being... I'm using Opera and loving it
Kubuntu with firefox 1.5 and 3 tabs open: 142mb is X virtual memory
Adding the config setting didn't have any effect on the ram usage but sped it up minimizing and closing /opening new tabs.
I dunno I never had a problem with firefox, so I dunno.
Then you haven't been using version 1.5