[prev in list] [next in list] [prev in thread] [next in thread] 

List:       opensuse
Subject:    Re: [opensuse] Firefox memory leak
From:       "Carlos E. R." <carlos.e.r () opensuse ! org>
Date:       2014-08-30 14:06:26
Message-ID: alpine.LSU.2.11.1408301536500.5597 () Telcontar ! valinor
[Download RAW message or body]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



On Wednesday, 2014-08-27 at 11:45 -0500, Jim Sabatke wrote:
> On 08/27/2014 10:33 AM, Cristian Rodríguez wrote:
> > El 27/08/14 a las #4, Jim Sabatke escribió:
> > > For quite some time, and across a couple versions of OpenSuse (13.1
> > > currently) I've had terrible problems with Firefox.  It displays the
> > > usual memory leak problems that programs often show, getting slower and
> > > slower until it becomes unresponsive until I kill it and restart.
> > 
> > While there might be indeed a memory leak. 99% of the time what users 
> > report as memory leak is a failure of understanding about how memory 
> > management works, what are the limitations, tradeoffs etc.. or a different 
> > problem altogether.
> > 
> > 
> I should have mentioned that I've run a system monitor and have watched 
> Thunderbird take up more and more memory until it stops responding.  I 
> realize people often don't understand memory management.  Back in the old 
> days, I wrote memory management software for embedded systems and even a 
> floppy disk controller with memory management.  I've written routines that 
> track allocation and reported problem routines.  I had to really jump through 
> hoops to get Windows to behave well in those days.
> 
> The Firefox version supplied with later Suse versions, probably a plug-in, is 
> really causing problems.  I'm really not up on modern web technologies, but I 
> don't think memory management has changed all that much.  I do know that Java 
> is supposedly graceful in it's memory management, but as another respondent 
> suggested, it could be Javascript, and I know nothing about that.


- From top, in my machine:

   PID USER      PR  NI    VIRT    RES    SHR   SWAP S  %CPU  %MEM     TIME+ COMMAND
  5103 cer       20   0 2833720 1,308g  26992 210076 R 7,938 16,75 625:33.98 firefox
  5521 cer       20   0 1508248 297476  21944 290572 S 0,000 3,631  44:31.39 \
thunderbird-bin

The important figure seems to be 'RES', resident memory ussage. Yes, 
1.5 GB is about normal here.


In FF, browse to "about:about". Then you may notice an entry named 
"about:memory". Click on "measure". I just did, and found a single site 
using 350 MB (http://store.kobobooks.com/en-es/). I close the tab, start 
it again, and now has 18 MB. 'top' says " 1,241g".

I will try not to open and forget that particular tab.


If you use the "addblock plus" addon, it causes a lot of memory ussage per 
page, and lower page load speed, and it is uanavoidable (because the 
stylesheet is loaded once per frame, 4MB*N).

<https://blog.mozilla.org/nnethercote/2014/05/14/adblock-pluss-effect-on-firefoxs-memory-usage/>


<https://adblockplus.org/blog/on-the-adblock-plus-memory-consumption>

<http://www.reddit.com/r/programming/comments/25j41u/adblock_pluss_effect_on_firefoxs_memory_usage/>


page with 400 iFrames, With ABP, needs 1960MiB  \
<http://vimcolorschemetest.googlecode.com/svn/html/index-c.html>


Those links are a very intersting read to learn things about how browsers 
use memory and other things. It is mostly a chrome developer who does the 
explaining, not a mozilla one, but nevertheless he manages to explain why 
firefox is slowed by this addon, why it uses so much memory, and why it is 
unavoidable (or at least till somebody invents something). It is in the 
comments. The gist:

[–]Klathmon 416 points 4 days ago

Chrome Dev here. We see this (and much more) with chrome as well.

Adblock, noscript, ghostery, and other addons like them cause 90% of the 
issues we see in the forums.

At the very least, by running any of these you are:

     Increasing memory usage anywhere from 10% to 30%
     increasing overall cpu usage across all cores
     increasing overall load time of the page by about 15% to 50%
     completely screwing many of the optimizations that have gone into the
   browser, effectively making the multi-threaded nature of the browser
   fight itself.

This is because these programs need to interrupt any and all http calls to 
check them against a big list of "no-no" domains held in memory. If it 
matches, they remove the element from the dom so it doesn't load and let 
the browser continue.

This has the effect of making every single thread sync up each time the 
dom is updated, so these extensions can scan the new elements to ensure 
they aren't loading ads/scripts. Fancy stuff like threaded compositing, 
network predictors and prefetchers, and batched layout rendering are all 
abandoned when any one of these is in play.




Then, there are some pages that impact terribly the browser. Now my FF is 
using 11% CPU, constant, doing nothing. Typically it is 2% here. It means 
I have somewhere a page (a tab) from some media site running some 
javascript thing. In chrome, you can press "Shift + Esc" and you get a 
task manager. No such thing in FF, unfortunately, I can't know what page 
it is till I happen to close it - and I may have a hundred tabs opened. 
There is no button to "stop scripts in this tab", either (freeze this 
tab).



- -- 
Cheers,
        Carlos E. R.
        (from 13.1 x86_64 "Bottle" at Telcontar)

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iEYEARECAAYFAlQB2nMACgkQtTMYHG2NR9V+rwCZAfBNqnthNuag2taElPdpabB2
CQkAn1lF7RjsmYtY+lYMfk7OE9klYLzw
=z8cX
-----END PGP SIGNATURE-----


-- 
To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org
To contact the owner, e-mail: opensuse+owner@opensuse.org


[prev in list] [next in list] [prev in thread] [next in thread]