Categories
about:memory add-ons Firefox Memory consumption MemShrink

MemShrink progress, week 35

Add-ons

Zombie compartments were fixed in the following add-ons:  Customize Your Web (fixed by Rudolf Noe), GridTube (fixed by Costas B.), Do Not Track Plus (fixed by kiran).

Marco Bonardo changed the Places JS services in a way that prevents certain kinds of SQLite connection leaks.  As far as I can tell, this fixes leaks in the Delicious Bookmarks and CyberSearch add-ons.

Finally, Alexandre Poirot fixed a bug in the Add-on SDK that was causing zombie jetpack compartments in some cases when add-ons were disabled.

Memory Reporting

Hugh Nougher added a memory reporter for GPU memory on Windows 7 and Vista.  See the “gpu-committed”, “gpu-dedicated” and “gpu-shared” entries in about:memory’s “Other Measurements” list.

I reduced the amount of memory allocated when generating about:memory by about 35%.

Miscellaneous

Josh Aas implemented unloading for out-of-process plug-ins.  If one is unused for 3 minutes it will be unloaded.

Andrew McCreight improved cycle collector dumping, which is useful in certain debugging cases.

Quote of the week

LifeHacker did some browser performance tests.  Firefox 10 handily won the memory usage test, which involved loading sites in 9 tabs and then measuring.  I personally think this is a pretty meaningless test, but I won’t complain about the good press.

As usual, the comments on the article featured a lot of debate about  whether Firefox is a memory hog or not.  One comment particular caught my attention:

They hardly used to be myths. I saw several times when old FF2x would be taking up over 1.4GB of RAM with just half a dozen tabs open.

Firefox 2 was released in October 2006, and superseded by Firefox 3 in June 2008.  Bad reputations are really difficult to shake.

Bug counts

This week’s bug counts:

  • P1: 26 (-0/+4)
  • P2: 131 (-6/+3)
  • P3: 76 (-2/+3)
  • Unprioritized: 1 (-2/+1)

22 replies on “MemShrink progress, week 35”

The bad reputation also comes from the fact that Firefox has been marketed at its beginning as a lightweight alternative to Internet Explorer. Some long-time users felt betrayed when it started beginning to be a memory hog, as they had thought this would never happen. MemShrink and Snappy are nice initiatives to go back to the light side of the Force.

We didn’t market Firefox as lightweight. It was always marketed as a full-featured (many more features than IE) product. Some users thought that it seemed to have limited features, but that wasn’t true. It used more RAM than IE when we shipped Firefox 1. It was quantitatively slower than IE when we shipped Firefox 1. But it had great features and it wasn’t bogged down with 3rd party toolbars and malware so it “seemed” better. But if you really compared a fresh Firefox 1.0 with a fresh IE 6, IE 6 was significantly faster and lighter than Firefox.

– A

Didn’t market it as lightweight? Then what is supposed to distinguish Firefox/Firebird/Phoenix from Seamonkey? Firefox has always been Seamonkey light, or so I thought.

The Readability extension causes leaks, long pauses, and crashes on shutdown. The browser becomes very slow after about 1 to 2 hours. It doesn’t cause obvious, repeatable zombie compartments though.

What’s the best way to record some data of a session with it installed, so that the devs can analyse the bug?

(having a problem with a “security code”, so 2nd attempt to post this)

The Readability extension causes leaks, long pauses, and crashes on shutdown. The browser becomes very slow after about 1 to 2 hours. It doesn’t cause obvious, repeatable zombie compartments though.

What’s the best way to record some data of a session with it installed, so that the devs can analyse the bug?

Can you make “compartment” description not overflowing the screen size in the verbose mode? Due to the URL inclusion, it simply overflows the screen width now (10.0.0.1)

It’s great to see several Add-On leaks fixed. Nicholas do you think the huge problems with Firebug leaks (immortal zombie compartments) will ever be fixed? It really pains me to see that Mozilla doesn’t care enough about fixing this problem.

It’s bizarre that you quoted Lifehacker because since a recent design change I can no longer load their pages! Typing into this box just now was super laggy. I thought overall memory usage had jumped to more than physical memory again. However it was a Lifehacker tab.

I am the one percent!

At least (according to Asa) the one percent which does not restart the browser daily as there’s no need to unless mandated by application or OS updates (same with other apps for mail, twitter, etc.). So it’s not uncommon that my Firefox instance will run for a week or longer easily. I’m using Fx10 on OX 10.7 and noticed that heap-unclassified is slowly growing over time. After a restart it usually accounts for about 50 MB of the memory usage but over a couple of days it rises to 300MB and above and apparently keeps rising slowly. Are there any patches in the pipeline for Fx11+ which will decrease heap-unclassified and make it easier to check where the memory is going?

I am the one percent!

At least (according to Asa) the one percent which does not restart the browser daily as there’s no need to unless mandated by application or OS updates (same with other apps for mail, twitter, etc.). So it’s not uncommon that my Firefox instance will run for a week or longer easily. I’m using Fx10 on OX 10.7 and noticed that heap-unclassified is slowly growing over time. After a restart it usually accounts for about 50 MB of the memory usage but over a couple of days it rises to 300MB and above and apparently keeps rising slowly. Are there any patches in the pipeline for Fx11+ which will decrease heap-unclassified and make it easier to check where the memory is going?

I’m gradually reducing heap-unclassified. I can’t remember what changes are pending for FF11, though, sorry.

Nicholas, thank you for the continue movement on this project. MemShrink and Snappy are critical to firefox, and I sense that you’re finally walking in the right direction, here ‘you’ refer to the mozilla community. Taras and you are leading the real critical projects for the future of firefox. As Asa stated, firefox is always a feature rich browser, and almost always far beyond reached by the competitors in terms of features. However people are still getting away regardless the rich features. So keep on focusing/spending more resource on improving performance, fixing Snappy and MemShrink bugs. I keep tracking both Snappy and MemShrink P1 bugs. 67 for Snappy and 26 for MemShrink now, and most of them are really hard bugs. We(the old firefox users) hope to sense a completely new firefox after 12 months that has get rid off most of these performance problems(less than 5 P1 bugs left unresolved) and become really competitive. Thank you.

Can I offer my computer for some tests? I can handle running any scripts or debug versions if necessary.

After about a day of using my browser, MemChaser shows I’m getting 300ms GC time, and 600ms CC time.

I forwarded this comment to a couple of the guys who work on the cycle collector in case they need some help.

I don’t know anything about that stuff, sorry. You could try asking at support.mozilla.org.

Comments are closed.