It’s been a busy couple of weeks for MemShrink.<\/p>\n
about:memory is our main tool for understanding memory consumption. On desktop Firefox it works very well.\u00a0 On Firefox mobile it works less well, partly because it’s hard to read all that text on a small screen, and partly because you can’t cut and paste, which makes bug reporting difficult<\/span>.\u00a0 And on B2G (a.k.a. Firefox OS) it currently doesn’t work at all.<\/p>\n To remedy this, I implemented the ability to import and export memory reporter data in JSON format<\/a>, and Justin Lebar sped up the exporting of this data and implemented a signal-based mechanism for triggering it<\/a>.\u00a0 The idea is that developers can trigger an export of the data from their device and then view it in about:memory in desktop Firefox.<\/p>\n This will allow detailed memory profiling for B2G, which I have listed as #3 on the current MemShrink “big ticket items” list<\/a>.\u00a0 The timing is good, because B2G has reached feature-freeze and so focus will now move to its performance and memory consumption as part of “Operation Slim Fast<\/a>“.<\/p>\n (On a related note, Kartikaya Gupta and other engineers have started looking closely at the memory consumption of Firefox mobile on low-end devices<\/a>.)<\/p>\n I added memory reporting to IonMonkey<\/a>.\u00a0 Happily, it appears to use very little memory, especially compared with JaegerMonkey.\u00a0 This is partly because it generates smaller code than JaegerMonkey, but mostly it’s because IonMonkey is only used to compile the small fraction of code that has been executed many 1000s of times.\u00a0 In comparison, JaegerMonkey is used to compile the much larger fraction of code that has been executed more than a few times.<\/p>\n Kyle Huey added memory reporters for attribute nodes and attribute maps<\/a>, which improves the coverage of the memory reporting for the DOM.<\/p>\n Kyle Huey optimized the representation of repeated inline style rules<\/a>.\u00a0 This means that for pages with many elements of the form Kyle Huey and Olli Pettay fixed a leak relating to web workers<\/a>.<\/p>\n Patrick McManus fixed a leak in network code that was causing intermittent oranges for Mochitests<\/a>.<\/p>\n Seth Fowler made nsConsoleService only post a LogMessageRunnable to the event queue if there are any observers for it<\/a>.\u00a0 This can save a lot of memory for pages that contains many errors.<\/p>\n An ongoing problem we have is that badly-written graphics drivers can cause outlandish (e.g. multi-GB) memory consumption.\u00a0 Here’s one example<\/a> that was fixed by blocklisting one particular AMD driver<\/a>.\u00a0 (That driver was also causing lots of crashes.)<\/p>\n It’s got to the point that if someone is seeing excessive memory consumption with no apparent explanation — e.g. immediately after start-up, with few tabs open — I’ll suggest they set layers.acceleration.disabled to true in about:config and there’s a good chance it’ll fix the problem.\u00a0 (Restarting in safe mode also disables hardware acceleration.)\u00a0 I don’t have any good ideas on how to improve this situation.<\/p>\n Here are the current bug counts.<\/p>\n In today’s MemShrink meeting we closed and downgraded a number of P1 bugs that (a) have been partially addressed, or (b) are less important than they first seemed, or (c) are duplicates.<\/p>\n","protected":false},"excerpt":{"rendered":" It’s been a busy couple of weeks for MemShrink. B2G Memory Reporting about:memory is our main tool for understanding memory consumption. On desktop Firefox it works very well.\u00a0 On Firefox mobile it works less well, partly because it’s hard to read all that text on a small screen, and partly because you can’t cut and […]<\/p>\n","protected":false},"author":139,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[4261,30,4544,4546],"tags":[],"_links":{"self":[{"href":"https:\/\/blog.mozilla.org\/nnethercote\/wp-json\/wp\/v2\/posts\/2327"}],"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=2327"}],"version-history":[{"count":0,"href":"https:\/\/blog.mozilla.org\/nnethercote\/wp-json\/wp\/v2\/posts\/2327\/revisions"}],"wp:attachment":[{"href":"https:\/\/blog.mozilla.org\/nnethercote\/wp-json\/wp\/v2\/media?parent=2327"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.mozilla.org\/nnethercote\/wp-json\/wp\/v2\/categories?post=2327"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.mozilla.org\/nnethercote\/wp-json\/wp\/v2\/tags?post=2327"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}Generic Memory Reporting<\/h3>\n
Gecko Slimmings<\/h3>\n
<foo style=\"blah\"><\/code>, the repeated style=\"blah\"<\/code> part is now shared between the elements.\u00a0 This is a huge win on certain large, auto-generated pages.\u00a0 For example, on one page that holds a gigantic Mercurial diff<\/a>, this change reduced 64-bit Firefox’s memory consumption from 1,759 MiB to 1,306 MiB.<\/p>\nBad Graphics Drivers<\/h3>\n
Bug Counts<\/h3>\n
\n