{"id":1020,"date":"2011-07-13T15:12:10","date_gmt":"2011-07-13T04:12:10","guid":{"rendered":"http:\/\/blog.mozilla.org\/nnethercote\/?p=1020"},"modified":"2011-07-13T15:12:10","modified_gmt":"2011-07-13T04:12:10","slug":"memshrink-progress-week-4","status":"publish","type":"post","link":"https:\/\/blog.mozilla.org\/nnethercote\/2011\/07\/13\/memshrink-progress-week-4\/","title":{"rendered":"MemShrink progress, week 4"},"content":{"rendered":"

Firefox 7 is currently in the Aurora channel<\/a>.\u00a0 Its memory usage improvements have been getting a lot of attention this week, with many people reporting the 30% improvement claims from the official blog post<\/a>.\u00a0 I was worried about the post claiming a specific percentage improvement, because there are various ways to measure memory usage, and it varies so greatly depending on the workload, but I haven’t seen anybody dispute it so far.\u00a0 In fact, the only non-Mozilla measurement I saw was one where a reviewer\u00a0 opened 117 bookmarks at once<\/a> (one bookmark per tab) and saw a 40% reduction in private bytes on Windows!\u00a0 This was a pleasant surprise as we were expecting improvements mostly when users (a) closed lots of tabs, or (b) left the browser idle for a long time.<\/p>\n

The most significant MemShrink-related landings this week were things that were subsequently backed out.\u00a0 Paul Biggar landed jemalloc support for Mac<\/a>, then had to revert it due to some crashes and possible memory usage regressions.\u00a0 This support has ended up being an enormous hassle, and Paul’s been tirelessly battling various Mac OS X quirks and annoyances over a period of several months.\u00a0 An earlier appraisal that “It should be pretty trivial…\u00a0I don’t think any of this would be a ton of work. Maybe a week of trying a few different things and running it through our unit tests?<\/a>” turned out to be spectacularly wrong.\u00a0 Hopefully Paul will be able to fix the problems and re-land soon.<\/p>\n

Brian Hackett merged his JavaScript type inference<\/a> from the jaegermonkey<\/a> repository to the tracemonkey<\/a> repository.\u00a0 Type inference speeds up computationally-intensive JavaScript code significantly<\/a>, but unfortunately it increased memory usage a lot, due to (a) the memory required for the analysis itself, and (b) some extra memory used by the executing JavaScript code.\u00a0 As a result, Brian had to back it out from the tracemonkey repository.\u00a0 He’s now making good progress on reducing the overhead<\/a>.\u00a0 One reason that this happened is that the jaegermonkey repository gets very little use, so the problem wasn’t noticed until it landed on the tracemonkey repository which gets more use.\u00a0 So if you want to help Brian out, please try browser builds from the jaegermonkey repository.<\/p>\n

On the tools front:<\/p>\n