This is a follow-on bug from bug 598466 (and bug 615199, which blocked it), which covered various memory size reductions and problems in Firefox 4. The following as-yet-unresolved bugs were carried over from that bug: bug 618031, bug 632012, bug 629601, bug 630447, bug 630738, bug 631045. Note that this bug is intended to be about slimming down memory usage, eg. reducing the size of data structures. It's not about leaks and quasi-leaks; bug 640452 is tracking those.

Do we have a bug for better accounting in about:memory? My current session uses 960MB private bytes, but the various allocation pools only account for about 200MB. If we could get a larger coverage it would make it easier to pin down where we can get the most savings.

(In reply to comment #1) > Do we have a bug for better accounting in about:memory? Bug 633653.

I feel that it would be useful to have a bug along the lines of: "Investigate why automated testing did not detect a 200-250% increase in per tab memory usage between 3.6.12 and Fx 4b4 / fill any gaps in testing" (ie: why all the regressions from bug 598466 managed to slip past and making sure it doesn't happen again) Is there one already for this?

Bug 643651 is a good (extreme) example of FF4's comparatively large memory use on image heavy pages (~1.5GB in this example, with peak memory > 2GB). Should it be added to this meta bug? https://bugzilla.mozilla.org/show_bug.cgi?id=643651

DB Cooper: yes! I've added it to this bug's list of blockers.

Now that we have even shorter release cycles than the originally planned 3 month ones, I've changed this to be about Firefox 5 and on. If this bug gets too unwieldy I'll close it out and start a new one.

There are various bugs relating to very large memory consumption when loading large (e.g. 1-2MB) XML files: bug 106357, bug 291643 and bug 436150 (maybe others as well).

Reece: thanks for the info. I ended up marking bug 160357 and bug 436150 as duplicates of bug 291643, because the latter has a good analysis.

This tracking bug has reached the end of its useful life. All the still open blocking bugs have had their whiteboards marked with "MemShrink", and so will be tracked that way by the MemShrink project.