It’s been a huge week for MemShrink.<\/p>\n
I filed a bug on testing the top 100 add-ons for memory leaks<\/a>.\u00a0 The majority of these add-ons are not available on AMO and so are not subject to the leak checking done during AMO reviews.\u00a0 The instructions and current test results are here<\/a>.\u00a0 Randell Jesup helped identify some some add-ons with unclear identities, and Nils Maier and Archaeopteryx have both tested several add-ons.\u00a0 A month ago I said that add-ons that leak are the #1 problem for MemShrink<\/a>, and this bug represents a huge step towards reducing that problem.\u00a0 We’ll need lots of additional help to test this many add-ons, so please feel free to jump in!<\/p>\n As far as I know, comprehensive testing of the most popular add-ons has never been done before.\u00a0 Although this testing is aimed at finding memory leaks, it’s quite possible it will uncover various other problems with add-ons.\u00a0 Indeed, it’s clear just from looking at the list that quite a few of the non-AMO add-ons are of dubious merit, and this has stimulated some interesting discussion on dev-platform<\/a> about third-party add-ons, i.e. those that are installed into Firefox by an external program.<\/p>\n The following add-ons had leaks fixed or mostly fixed by their authors: McAfee Site Advisor<\/a>, Ghostery<\/a>, Spool,<\/a> Screengrab (fix version)<\/a>, Roboform<\/a>, UF Comment Board Tools<\/a>,\u00a0 Geenstijl,<\/a> Long URL Please<\/a>, HTML Desktop Notifications<\/a>.<\/p>\n Nils Maier greatly improved<\/a> the documentation on common causes of memory leaks in add-ons<\/a>.\u00a0 This was a MemShrink:P1 bug.\u00a0 That doesn’t mean the document can’t be improved further, however;\u00a0 it’s a wiki so please continue to add to it if you can.<\/p>\n John Schoenick’s excellent areweslimyet.com<\/a> is getting close to being ready for a public unveiling.\u00a0 The site is currently live but password-protected, simply to prevent large numbers of people accessing it before it’s ready.\u00a0 (If you want a sneak peek, contact me for the password.)\u00a0 More importantly, it identified a large regression in memory consumption<\/a> caused by the landing of the JS engine’s incremental garbage collector<\/a> on February 19, which Bill McCloskey is investigating.<\/p>\n Tim Taubert improved Firefox’s regression testing to ensure that no new DocShell and DOMWindow leaks are introduced<\/a>.\u00a0 This was a MemShrink:P1 bug because these leaks are quite easy to introduce.\u00a0 Tim wrote some more about this change here<\/a>.<\/p>\n Jan Honza Odvarko’s about:ccdump add-on made it onto AMO this week<\/a>.\u00a0 Jan has been using this to hunt down some tricky leaks in Firebug<\/a>.<\/p>\n Marco Bonardo fixed a leak in PlacesUtils.removeLazyBookmarkObserver()<\/a> that I won’t pretend to understand, but which was a MemShrink:P1.\u00a0 Marco also fixed a leak that occurred after bookmarking a page, closing the window, and opening a new window<\/a>.<\/p>\n Olli Pettay fixed an equally impenetrable (to me) leak involving nsFormFillController::mFocusedInput<\/a>.<\/p>\n Kyle Huey fixed a leak in the About Firefox dialog<\/a>.<\/p>\n Andrew McCreight added additional information to cycle collector’s error console logging<\/a>, which helps with identifying and debugging cycle collector problems.<\/p>\n Jason Duell fixed an obscure leak involve web sockets<\/a>.<\/p>\n Bill McCloskey fixed a minor JS engine leak<\/a>.<\/p>\n I added a new memory reporter called “js\/runtime\/gc-marker”<\/a>.\u00a0 It starts out at 256KB and I saw it reach 2.8MB when running MemBench<\/a>.\u00a0 I also converted the existing source image reporters to the new style<\/a>, which seems to haved fixed some bogus results in about:memory<\/a> as a side-effect.<\/p>\n Adam Overa of Tom’s Hardware did another browser Grand Prix<\/a>.\u00a0 Devin Coldewey used the results from the Grand Prix to conclude that Firefox and Chrome are both great, and which you prefer basically comes down to a matter of taste<\/a>.\u00a0 While that is an interesting conclusion, what caught my eye was this comment<\/a>, by Balaji Viswanathan:<\/p>\n I guess the title could have been “All browsers suck equally bad now”. Firefox and Chrome have grown to become more resources hogs – closer to IE. These days I shudder to fire up the firefox as the memory leaks are terrible. Two hours of Firefox with a Facebook tab is enough to gobble up 25% of my memory. With Chrome, I would have 20 rendering processes showing up when I would have just 3 tabs open.<\/p>\n In the first 2 years of Chrome I had probably 2 or 3 crashes. These days, it crashes every week or so. I long for the 2006 era Firefox – clean, simple and lean.<\/strong> Its been a long time since I have used IE actively and with Safari lesser said the better. For the developers, we have to deal with the ultra slow update cycles of IE and ultraspeed update cycles of Chrome. In short, we are getting worse and worse in the browser arena. The market is ripe for a breakthrough.<\/p><\/blockquote>\n “2006 era Firefox” would have been Firefox 1.5 or Firefox 2.\u00a0 Balaji may think he’s nostalgic for browsers of that era, but really he’s nostalgic for the web<\/em> of that era, which was massively simpler than the web of today.\u00a0 If Balaji tried Firefox 1.5 or Firefox 2 today — with no HTML5 support, no JavaScript JIT and no hardware acceleration — today, I’m sure he’d quickly decide that 2012-era browsers aren’t so bad after all.\u00a0 I guess the interesting question is this: why do people blame browsers instead of websites for high resource consumption?<\/p>\n This week\u2019s bug counts:<\/p>\n That’s a net reduction of one bug.\u00a0 But more importantly, there is lots of movement, which is great!\u00a0 It means that problems are being identified and fixed.<\/p>\n (Finally, commenters please note that I’ve turned on the WP-reCAPTCHA plug-in, and this the first post I’ve written since doing so.\u00a0 In my testing it’s worked fairly well.\u00a0 Hopefully it won’t cause problems.)<\/p>\n","protected":false},"excerpt":{"rendered":" It’s been a huge week for MemShrink. Add-ons I filed a bug on testing the top 100 add-ons for memory leaks.\u00a0 The majority of these add-ons are not available on AMO and so are not subject to the leak checking done during AMO reviews.\u00a0 The instructions and current test results are here.\u00a0 Randell Jesup helped […]<\/p>\n","protected":false},"author":139,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[4550,119,30,4555,4544,4546],"tags":[],"_links":{"self":[{"href":"https:\/\/blog.mozilla.org\/nnethercote\/wp-json\/wp\/v2\/posts\/1794"}],"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=1794"}],"version-history":[{"count":0,"href":"https:\/\/blog.mozilla.org\/nnethercote\/wp-json\/wp\/v2\/posts\/1794\/revisions"}],"wp:attachment":[{"href":"https:\/\/blog.mozilla.org\/nnethercote\/wp-json\/wp\/v2\/media?parent=1794"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.mozilla.org\/nnethercote\/wp-json\/wp\/v2\/categories?post=1794"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.mozilla.org\/nnethercote\/wp-json\/wp\/v2\/tags?post=1794"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}Regression testing<\/h3>\n
Cycle collector<\/h3>\n
Miscellaneous<\/h3>\n
Quote of the week<\/h3>\n
Bug counts<\/h3>\n
\n