Closed Bug 340372 Opened 15 years ago Closed 10 years ago
Memory usage report by DOM object for debugging memory problems
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1a2) Gecko/20060512 BonEcho/2.0a2 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1a2) Gecko/20060512 BonEcho/2.0a2 Please add the following feature to Mozilla/Firefox : Memory usage report by URL or tab or DOM object for debugging memory problems. If there are memory allocations that cannot be associated with a specific URL/tab since they belong to 2 or more objects, list them as shared. The exact details of the report should be determined by discussion later. There should also be probably a section of memory usage for the chrome (the apppliation GUI) itself. This can help non-technical users of Mozilla to have easier debugging of memory and memory leak problems by pointing them faster to where the problem might be. For example, if the memory is used by leaking flash ads due to a bug in the flash plugin that causes the memory use to grow after several days of use, I will see in the report the URLS with the highest memory usage, and I can dig to the details, and see that the objects using the most memory are the flash ads in this URL. This can also help to know that the problem is due to a memory leak if the memory reported by the task manager deviates substantially from the total memory reported by this suggested memory report. A sample implementation idea: From my limited knowledge I think that DOM has some kind of tree structure. So for each DOM object you can add 2 functions, get_memory_used(), and get_shared_memory_used(). Leaf objects return their memory use, and memory that is attributed to shared memory (memory that is used by more than one object). Non-leaf objects call their children to get their memory usage, and return the sum of their children plus their own direct memory use. Reproducible: Always Steps to Reproduce: 1. Not applicable - this is a feature request Actual Results: There is no memory use report in Mozilla/Firefox :) Expected Results: There should be a memory use report in Mozilla/Firefox :)
Assignee: nobody → general
Component: General → DOM
Product: Firefox → Core
QA Contact: general → ian
Version: unspecified → Trunk
Assignee: general → nobody
QA Contact: ian → general
Is this a dupe of bug 167035?
It seems more similar to bug 515354, but not identical. bug 167035 doesn't mention grouping the memory usage per tab,windows and per DOM objects, or plugins. I think that bug 515355 also doesn't mention this memory usage groupings, just a general statement of implementing about:memory similar to chrome.
Status: UNCONFIRMED → RESOLVED
Closed: 11 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 400120
Whatever. Can't we spend some time actually implementing things instead of arguing ad infinitum how to it ? Ok, now you have your wish. It still depends on bug 400120. Or vice versa.
Status: RESOLVED → UNCONFIRMED
Depends on: 400120
Resolution: DUPLICATE → ---
(In reply to comment #5) > Whatever. Can't we spend some time actually implementing things instead of > arguing ad infinitum how to it ? > > Ok, now you have your wish. It still depends on bug 400120. Or vice versa. Nobody was arguing about anything, and implementation is non-trivial. I'd say that this could definitely be a useful feature, so I'm confirming it. It does rely on the implementation of memory tracking, though, so it waits on bug 400120. (I've modified the summary of this bug to focus solely on the DOM object memory tracking, so as to further differentiate it from that bug.)
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Memory usage report by URL/tab/DOM object for debugging memory problems → Memory usage report by DOM object for debugging memory problems
Per-compartment memory reporting (bug 661474) will partly satisfy this request: bug 661474. DOM memory reporters (bug 663271) will also partly satisfy this request. They won't get to the granularity of individual objects -- there could be thousands of them, it's too much data -- but they should be detailed enough to be useful. So I'm going to mark this as a duplicate of bug 663271. It's not a perfect duplicate, but since nobody has actually worked on this specific request this seems a reasonable course of action.
Status: NEW → RESOLVED
Closed: 11 years ago → 10 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 663271
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.