Categories
Firefox Memory consumption MemShrink

MemShrink progress, week 103–104

I’m back from vacation.  Many thanks to Andrew McCreight for writing two MemShrink reports (here and here) while I was away, and to Justin Lebar for hosting them on his blog.

Fixes

areweslimyet.com proved its value again, identifying a 40 MiB regression relating to layer animations.  Joe Drew fixed the problem quickly.  Thanks, Joe!

Ben Turner changed the GC heuristics for web workers on B2G so that less garbage is allowed to accumulate.  This was a MemShrink:P1.

Bas Schouten fixed a gfx top-crasher that was caused by inappropriate handling of an out-of-memory condition.  This was also a MemShrink:P1.

Randell Jesup fixed a leak in WebRTC code.

Changes to these progress reports

I’ve written over sixty MemShrink progress reports in the past two years.  When I started writing them, I had two major goals.  First, to counter the notion that nobody at Mozilla cares about memory consumption — this was a common comment on tech blogs two years ago.  Second, to keep interested people informed of MemShrink progress.

At this point, I think the first goal has been comprehensively addressed.  (More due to the  fact that we actually have improved Firefox’s memory consumption than because I wrote a bunch of blog posts!)  As a result, I feel like the value of these posts has diminished.  I’m also tired of writing them;  long-time readers may have noticed that they are much terser than they used to be.

Therefore, going forward, I’m only going to post one report every four weeks.  (The MemShrink team will still meet every two weeks, however.)  I’ll also be more selective about what I write about — I’ll focus on the big improvements, and I won’t list every little leak that has been fixed, though I might post links to Bugzilla searches that list those fixes. Finally, I won’t bother recording the MemShrink bug counts.  (In fact, I’ve started that today.)  At this point it’s pretty clear that the P1 list hovers between 15 and 20 most of the time, and the P2 and P3 lists grow endlessly.

Apologies to anyone disappointed by this, but rest easy that it will give me more time to work on actual improvements to Firefox 🙂

16 replies on “MemShrink progress, week 103–104”

just wanted to say that I like reading this status reports. They are short and direct.
Thank you for the good work

I’ll add my voice to the chorus. I’ve also enjoyed reading these posts, and the insight provided to the ongoing work at Mozilla.

I really like memshrink reports, as I like the performance report from other people of mozilla. They make the difference in my eyes, seems like people are hard at work to make firefox even better. Completely different from viewing the usual release notes that contains a few changes, mostly useless, and then it seems like another “pointless” release…

Welcome back!
Hope you had a great vacation!
Your past updates have served Mozilla and the community well.

I’ll agree with AV, reading people talk about the work they’re doing to improve Firefox makes it much easier to stay excited and looking forward to new versions. A once-monthly post is a bit thin on that count… I’d like to read more. But: it doesn’t have to be systematic, formulaic reports – just posting any interesting developments as they happen would be fine if that’s easier. Also: if you are worn out, maybe someone else can pick up the slack. (People do burn out. It’s normal.) I’d equally appreciate links to people who already write about memshrink work with some frequency.

Whatever the case, though – thanks for making the journey so far interesting to follow along with. It’s been enjoyable. (And of course, thanks for the work itself! For making my workhorse browser so much better.)

Thanks for all your hardwork! Writing up progress reports can often be thankless work, but you have trudged through these MemShrink reports faithfully for such a long time and I know the Mozilla and Firefox communities are better for it.

I would just add: Please don’t stop altogether.

Every 4 weeks is more than frequent enough, providing you keep us updated with the most important Memshrink changes. You’ve done epically well to keep going with the updates at the current frequency as long as you have, and I thank you for that.

Links to the latest memshrink fixes would be greatly appreciated, even if you just give the numbers of certain bugs that you think are worth watching.

For non-technical people like me, I enjoyed your updates as they helped me make sense of what was being changed and why it was an improvement, even if I didn’t fully understand what you had written.

Aww. Waiting a month on the new MemShrink blog seemed like forever to me (I didn’t now about the substitution blogs), it’s a pity to hear that you’ll drop the frequency. But I do understand that you’re getting tired of it after two years. I’d like to thank you for your effort, and one blog a month is still way better than it used to be before you started them 🙂 (i.e. don’t hear anything at all about it)

Just a quick question passing by my mind: do you think Australis will influence Firefox’s memory usage? If so, how? Will there be an AWSY run of the UX branch before it gets merged?

P.S. Yay, I think this is the second time a bug of mine has been mentioned in your blog \o/

I could be wrong, but I suspect Australis won’t make much difference. The UX guys could request an AWSY run before merging but I’m not expecting it.

I also enjoy the memshrink reports. My only suggestion would be that major pieces of news (like updating the list of “big ticket items”) be put in a separate post, as it helps them stand out and makes them easier to find later. But that’s really minor. Thanks for all the hard work!

I would say that knowing that memshrink is active pushed me to do a bug report in the last weeks about pdf.js. It has since been moved into the memshrink keyword.

If I did not know that this is actively looked at I would be not had sent in the bug.

So drop the frequency, but don’t stop if you want to continue to get
bug reports — one quickly learns that other parts of mozilla are less reactive (hmm sql…). I think writing brings in reports that you would not otherwise get

Hey Nick,

Nice to have you back – like everyone has said already, we look forward to your posts!

Have you noticed the slow but steady upward tick in RSS (fresh start) and RSS (fresh start +30s) since April 5th? It will be hard for the team to pinpoint one regression that caused this uptick, but it looks like this pushlog started it all: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=e636439e342f&tochange=72fcb7c13613

Thanks,
Manoj

I thought I would add a little note to thank for these regular posts.
You wrote every week almost without skipping any which is great and kept everyone interested.
I’m confortable with a 4 weeks frequency.
Due to your work on posts during the past 2 years I’m sure you’ll write every 4 weeks and it’s not a sign that you will start skipping posts writing. But just in case please don’t stop :-p

Keep up with the wonderful work on Firefox memory ! Thanks a lot !

Thanks Nick for all your hardwork and dedication to these updates. I really appreciate all the time and effort you must have put into these.

Could you give us some links of other bloggers who write regularly about different parts of firefox. It would be good to know about improvements in other areas of firefox as well.

Cheers,
Ameya

There are plenty, and they’re all on planet.mozilla.org, but it also includes lots of non-technical posts. Possibly your best bet is http://www.reddit.com/r/mozillatech, which is a subreddit that lists the more technically-oriented blog posts from Planet.

Comments are closed.