Firefox eats my CPU like I eat ribs

[rlk-FrUbXkNCsVf2fBVCVOL8/A at public.gmane.org (Robert Krawitz)]

   Date: Sat, 28 Mar 2009 20:57:04 -0400
   From: Greg Rundlett <greg_rundlett-nRXb03v5zC6Vc3sceRu5cw at public.gmane.org>

   On Sat, Mar 28, 2009 at 5:23 PM, Danny Robert <daniel.robert-HInyCGIudOg at public.gmane.org> wrote:
   > Unfortunately my only evidence is anecdotal, but whenever firefox is
   > eating my CPU I've always found it to be the flash plugin. ?Wish I had
   > more to offer.

   I've had some similar episodes and have found that the last plugin
   that I added was causing the problem.  Or, in the case of a Firefox
   update, an existing plugin started to misbehave.   So, the two
   solutions are to disable a plugin one at a time until you find the one
   that is not working well.  Or, you can install a clean profile (using
   profile manager) and see if Firefox works well with no plugins - -
   then start adding.

   Note: FF just released a security update (today?) to 3.0.8

I've found that killing off pages one by one usually helps track down
what's going on.  Facebook is a big offender in this regard, but
anything that uses Flash (having a video embedded, even if it's not
active, seems to cause problems as well).

I have another FF resource consumption issue: the 64-bit version of
Firefox consumes a lot more memory than the 32-bit version, on
OpenSUSE 11.1 (this is using OpenSUSE's FF builds -- I'm not comparing
an OpenSUSE build with an official Mozilla build).  What I find is
that the 64 bit version balloons to 450 MB even with an empty profile;
when I load my typical session, it's up to 900 MB or so and takes off
from there.  In contrast, the 32 bit version is more like 100 MB
empty; with all of my extensions and session loaded, it climbs to
about 300 MB.

This isn't due to plugins (there are a lot more 64 bit vs. 32 bit
plugins on my system); even if I move /usr/lib64/browser-plugins out
of the way, an empty session with no extensions starts out at 450 MB.
It looks like the heap is the cause of this.  64 bit pointers are of
course 2x the size, but non-pointer data shouldn't be any bigger, and
this wouldn't account for the well over 2x bloat factor.

I haven't had much luck finding anything on the net about this.

-- 
Robert Krawitz                                     <rlk-FrUbXkNCsVf2fBVCVOL8/A at public.gmane.org>

Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail lpf-BtI67efEdsDk1uMJSBkQmQ at public.gmane.org
Project lead for Gutenprint   --    http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton