Once those bugs are fixed, my hope is that someone with better UX skills than me will write a easy-to-understand, high-level UI for seeing the per-tab memory usage, much like what you’ve done.

aboutMemory.js has been changing a lot lately, and will continue to do so. I’ve done some stuff to make it allocate less memory, see https://bugzilla.mozilla.org/show_bug.cgi?id=722969 and https://bugzilla.mozilla.org/show_bug.cgi?id=722972. Even after the latter bug is fixed it’ll still be way too inefficient for running once per second!

Ping me on IRC (“njn” on #memshrink) if you want to talk more!

It would indeed be great if we had more knobs for the memory reporters and could be more memory efficient. I’m not sure it’s worth the complexity at this point, but I think it would be good to keep in mind for the next time the infrastructure needs to be rejiggered so that it can also support abuses of it such as this one

Hmm… how hard would it be to highlight suspected zombie compartments? (And with it, “This compartment has been alive for 326 seconds since the last tab/docshell/whatever containing it was closed”?) And render them with a rotting flesh background texture?

Hmm… I wonder if there’s a way for the slower memory reporters only sample a subset of their items. It’d be nice to slow down and stagger the sampling for inactive tabs.

Dindog, internally, the interval is configurable, so it should be fairly easy to expose that, especially now that I believe the add-on SDK has an easy-to-use preferences mechanism that automatically surfaces a UI.

Px, I fear that the problem may be with the Add-on SDK not liking SeaMonkey rather than my extension. Specifically, I know it likes to check the application id in many cases and throw if it thinks it doesn’t support the app. That’s my best guess as to what is happening.