{"id":2684,"date":"2013-10-01T12:23:08","date_gmt":"2013-10-01T01:23:08","guid":{"rendered":"http:\/\/blog.mozilla.org\/nnethercote\/?p=2684"},"modified":"2013-10-02T09:31:17","modified_gmt":"2013-10-01T22:31:17","slug":"memshrink-progress-week-117-120","status":"publish","type":"post","link":"https:\/\/blog.mozilla.org\/nnethercote\/2013\/10\/01\/memshrink-progress-week-117-120\/","title":{"rendered":"MemShrink progress, week 117–120"},"content":{"rendered":"

Lots of important MemShrink stuff has happened in the last 27 days:\u00a0 22 bugs were fixed<\/a>, and some of them were very important indeed.<\/p>\n

Images<\/h3>\n

Timothy Nikkel fixed bug 847223<\/a>, which greatly reduces peak memory consumption when loading image-heavy pages.\u00a0 The combination of this fix and the fix from bug 689623<\/a> — which Timothy finished earlier this year<\/a> and which shipped in Firefox 24 — have completely solved our longstanding memory consumption problems with image-heavy pages!\u00a0 This was the #1 item on the MemShrink big ticket items list<\/a>.<\/p>\n

To give you an idea of the effect of these two fixes, I did some rough measurements on a page<\/a> containing thousands of images, which are summarized in the graph below.<\/p>\n

\"Improvements<\/a><\/p>\n

First consider Firefox 23, which had neither fix, and which is represented by the purple line in the graph.\u00a0 When loading the page, physical memory consumption would jump to about 3 GB, because every image in the page was decoded (a.k.a. decompressed).\u00a0 That decoded data was retained so long as the page was in the foreground.<\/p>\n

Next, consider Firefox 24 (and 25), which had the first fix, and which is represented by the green line on the graph.\u00a0 When loading the page, physical memory consumption would still jump to almost 3 GB, because the images are still decoded.\u00a0 But it would soon drop down to a few hundred MB, as the decoded data for non-visible images was discarded, and stay there (with some minor variations) while scrolling around the page. So the scrolling behaviour was much improved, but the memory consumption spike still occurred, which could still cause paging, out-of-memory problems, and the like.<\/p>\n

Finally consider Firefox 26 (currently in the Aurora channel), which has both fixes, and which is represented by the red line on the graph.\u00a0 When loading the page, physical memory jumps to a few hundred MB and stays there.\u00a0 Furthermore, the loading time for the page dropped from ~5 seconds to ~1 second, because the unnecessary decoding of most of the images is skipped.<\/p>\n

These measurements were quite rough, and there was quite a bit of variation, but the magnitude of the improvement is obvious.\u00a0 And all these memory consumption improvements have occurred without hurting scrolling performance.\u00a0 This is fantastic work by Timothy, and great news for all Firefox users who visit image-heavy pages.<\/p>\n

[Update: Timothy emailed me this:\u00a0 “Only minor thing is that we still need to turn it on for b2g. We flipped the pref for fennec on central (it’s not on aurora though). I’ve been delayed in testing b2g though, hopefully we can flip the pref on b2g soon. That’s the last major thing before declaring it totally solved.”]<\/p>\n

[Update 2: This has hit Hacker News<\/a>.]<\/p>\n

NuWa<\/h3>\n

Cervantes Yu landed Nuwa<\/a>, which is a low-level optimization of B2G.\u00a0 Quoting from the big ticket items list<\/a> (where this was item #3):<\/p>\n

Nuwa… aims to give B2G a pre-initialized template process from which every subsequent process will be forked… it greatly increases the ability for B2G processes to share unchanging data.\u00a0 In one test run<\/a>, this increased the number of apps that could be run simultaneously from five to nine<\/strong><\/p><\/blockquote>\n

Nuwa is currently disabled by default, so that Cervantes can fine-tune it, but I believe it’s intended to ship with B2G version 1.3.\u00a0 Fingers crossed it makes it!<\/p>\n

Memory Reporting<\/h3>\n

I made some major simplifications to our memory reporting infrastructure, paving the way for future improvements.<\/p>\n

First, we used to have two kinds of memory reporters:\u00a0 uni-reporters (which report a single measurement) and multi-reporters (which report multiple measurements).\u00a0 Multi-reporters, unsurprisingly, subsume uni-reporters, and so I got rid of uni-reporters<\/a>, which simplified quite a bit of code.<\/p>\n

Second, I removed about:compartments<\/a> and folded its functionality into about:memory.\u00a0 I originally created about:compartments at the height of our zombie compartment problem.\u00a0 But ever since Kyle Huey made it more or less impossible<\/a> for add-ons to cause zombie compartments, about:compartments has hardly been used.\u00a0\u00a0 I was able to fold about:compartments’ data into about:memory, so there’s no functionality loss, and this change simplified quite a bit more code.\u00a0 If you visit about:compartments now you’ll get a message telling you to visit about:memory.<\/p>\n

Third, I removed the smaps (size\/rss\/pss\/swap) memory reporters.\u00a0 These were only present on Linux, they were of questionable utility, and they complicated about:memory significantly.<\/p>\n

Finally, I fixed a leak in about:memory<\/a>.\u00a0 Yeah, it was my fault.\u00a0 Sorry!<\/p>\n

Summit<\/h3>\n

The Mozilla summit is coming up!\u00a0 In fact, I’m writing this report a day earlier than normal because I will be travelling to Toronto tomorrow.\u00a0 Please forgive any delayed responses to comments, because I will be travelling for almost 24 hours to get there.<\/p>\n","protected":false},"excerpt":{"rendered":"

Lots of important MemShrink stuff has happened in the last 27 days:\u00a0 22 bugs were fixed, and some of them were very important indeed. Images Timothy Nikkel fixed bug 847223, which greatly reduces peak memory consumption when loading image-heavy pages.\u00a0 The combination of this fix and the fix from bug 689623 — which Timothy finished […]<\/p>\n","protected":false},"author":139,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[15267,4550,30,4544,4546],"tags":[],"_links":{"self":[{"href":"https:\/\/blog.mozilla.org\/nnethercote\/wp-json\/wp\/v2\/posts\/2684"}],"collection":[{"href":"https:\/\/blog.mozilla.org\/nnethercote\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.mozilla.org\/nnethercote\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.mozilla.org\/nnethercote\/wp-json\/wp\/v2\/users\/139"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.mozilla.org\/nnethercote\/wp-json\/wp\/v2\/comments?post=2684"}],"version-history":[{"count":0,"href":"https:\/\/blog.mozilla.org\/nnethercote\/wp-json\/wp\/v2\/posts\/2684\/revisions"}],"wp:attachment":[{"href":"https:\/\/blog.mozilla.org\/nnethercote\/wp-json\/wp\/v2\/media?parent=2684"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.mozilla.org\/nnethercote\/wp-json\/wp\/v2\/categories?post=2684"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.mozilla.org\/nnethercote\/wp-json\/wp\/v2\/tags?post=2684"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}