Lots of good stuff this week.
There were four great blog posts this week relating to memory usage in Firefox.
- Gregor Wagner compared Firefox and Google Chrome in a 150-tab stress test. Firefox won hands down. It appears that Chrome just can’t handle large numbers of tabs open at once; I’d be interested to hear if anyone can confirm or refute that finding.
- Gian-Carlo Pascutto described how he is making Firefox’s SafeBrowsing implementation more memory-efficient. This will fix problems seen in the existing implementation, and allow SafeBrowsing to be turned on in Fennec.
- Chris Pearce wrote about reducing the size of thread stacks.
- Steve Fink told the tale of a zombie (compartment) hunt.
Ben Turner landed a complete reworking of web workers. This fixed three MemShrink bugs, and probably a number of others. Ben also added memory reporters so that web workers show up in about:memory.
I always cringe when someone files a bug report complaining about Firefox’s memory usage and they have many (e.g. 10, 20 or more) add-ons installed. The chances of all of those add-ons behaving themselves is pretty low, unfortunately. For example, one user found that the CyberSearch 2.0.8 add-on causes the places SQLite database to grow to over 300MB. Another user found that one or more add-ons caused that same database to grow to 1.2GB(!); the add-on(s) responsible has not yet been identified.
This kind of thing is terrible for perceptions of Firefox. Maybe limiting the size of places.sqlite will help?
In better add-on-related news, Jan Honza Odvarko fixed a bad memory leak in Firebug, one that was causing zombie compartments on pages where Firebug hadn’t even been enabled. Now Firebug only causes zombie compartments for pages where Firebug has been enabled, but Steve Fink is making progress there, as he described in his blog post that I linked to above.
If you ask a heap allocator like jemalloc for a certain number of bytes, it’ll often round that request size up to a number such as a power-of-two. For example, if you ask for 99 bytes it’ll give you 112 or 128. I found that this is contributing to the high “heap-unclassified” number in about:memory. I also stumbled across two cases where Firefox itself deliberately requests a power-of-two-sized block of memory (with the aim of avoiding round-up in the heap allocator) but botches the calculation such that it asks for a block slightly bigger than a power-of-two, which jemalloc then rounds up again. Luke Wagner fixed the first of these, and I have patches awaiting review to fix the second.
Finally, I should mention bug 658738 and its children. Dão Gottwald and others have been working tirelessly to fix leaked windows in browser-chrome tests. This has involved both (a) fixing problems with the tests, and (b) fixing problems with the browser. Eleven child bugs have already been fixed, and there are four still open.
Here’s the change in MemShrink bug counts.
- P1: 27 (+1)
- P2: 53 (+4)
- P3: 35 (+2)
- P4: 11 (+5)
Increases all across the board. Once again I think this reflects the increasing amount of work being done… but I keep saying that. Therefore, beginning next week, I’ll show how many bugs in each category were fixed and how many were added, e.g. “P1: 27 (-2, +3)”. That’ll give a better idea of progress. (I can’t start it until next week because I’ve only today started recording enough info about the open bugs to get those numbers. And before you suggest that I use a time-based Bugzilla search instead, the problem with that is that I write this progress report at a slightly different time each week, so if I just search during the last week I may double-count or fail to count some bugs.)