(Feel free to improve upon the bug title.) Right now, Debugger.Memory.prototype.takeCensus traverses the heap graph and keeps a running count of the various types of things it sees using the Assorter abstraction. Jim tells me that nsIMemoryReporterManager's sizeOfTab just iterates every GC cell in the tab's zone and then using its own logic to categorize and count the things it sees. The advantage the latter has over the former is that it is much faster in practice (although Jim believes he can improve the former, I didn't get the impression that it would ever be as fast as the latter). There are two disadvantages to the latter approach: 1. You are potentially (in practice, actually) counting dead, waiting to be GC'd things that aren't actionable to web/app devs because you aren't actually traversing the heap graph from the GC roots. Not much to say about this, other than that it seems to be the cost of gaining increased perf. 2. The categories yielded by sizeOfTab are very coarse grained and leave one wishing for more detailed break downs. This problem seems very tractable. We could simply use our existing Assorter abstraction, which has proved to be both powerful and generic, for the categorization and counting bits, while using the iterate-gc-cells approach. The result would be a faster version of a census that provides just as detailed breakdowns/counts, but might (will) include some garbage. Is this worth investigating/prototyping?
I chose the coarse categories used by sizeOfTab fairly arbitrarily. There's plenty of room to modify them, esp. since (AFAIK) there's no code in the tree that actually uses sizeofTab.
You need to log in before you can comment on or make changes to this bug.