Confirm
1,345
edits
Changes
no edit summary
* Do we only measure peak usage? Or do we want to open and close lots of tabs to try to catch leaks?
* jseward's [http://blog.mozilla.com/jseward/2011/01/27/profiling-the-browsers-virtual-memory-behaviour/ VM-sim extension to Cachegrind] takes a different tack; it measures page faults on a quasi-idealized machine. It's slow, though.
== A Clear Goal ==
In terms of tracking bugs, now that we're on a 3 month release cycle, I like the idea of having one meta-bug tracking all memory use reductions for the next release. I personally find meta-bugs like this to be quite useful so long as they have a clear end-point. So I opened [https://bugzilla.mozilla.org/show_bug.cgi?id=640452 bug 640452] for leaks in Firefox 5 and and [https://bugzilla.mozilla.org/show_bug.cgi?id=640457 bug 640457] for other memory use reductions in Firefox 5.
== Other Ideas ==
=== An alternative approach ===
Good metrics are more difficult for memory usage than they are for cpu time. Mostly this is bad, but we may be able to use it to our advantage because it means it's harder for people to show that Firefox is using more memory than another browser. i.e. you can't load up the equivalent to sunspider in both browsers and immediately see which is better. This means that impact of bad memory usage is based on experience during regular browsing.
I wonder if we could add something to Firefox input like "Report Firefox using too much memory" we could then upload the contents of about:memory. This can help us get a better picture of when our users have the perception that we're using too much memory. It also gives us a better opportunity to discover memory leaks that are happening in the field.
