Closed Bug 932553 (Find-dom-frag) Opened 11 years ago Closed 6 years ago

Find orphaned DOM fragment leaks in a Recording

Categories

(DevTools :: Memory, defect)

x86
macOS
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED INVALID

People

(Reporter: akratel, Unassigned)

References

Details

(Whiteboard: [User Story], [mockup])

User Story

As a web/app developer, i would like to find any orphaned DOM fragment leaks so that I can properly optimize my JS code for least memory consumption.

Acceptance Criteria:
- DOM elements not attached to the DOM are broken off and above a certain lifetime threshold are highlighted
- able to distinguish DOM leaks from DOM fragments, since some DOM fragments are ok to have around as long as they are short lived.
- The relevant JS and DOM memory amounts are given
- JS References are shown
- Able to navigate to the code references

Note: this is a bit of a holy grail for perf management on HTML5 apps. This could also be done in "report" style, i.e. run some sort of analysis on the recording and report back. But I suspect it would be easier to relate events causally, i.e. find where the fragments break off, and see what code was executed shortly before. 

Note: DOM fragments are not bad in themselves, it's just if they hang around and keep growing that they become a problem. We have to find the ones that still have dangling JS references and don't get GC'd. See these simple tests that compare keeping the fragments around versus removing them: http://jsperf.com/create-dom-fragments. 

Expect that some research will need to go into this user story before it goes into implementation. 

Example test cases: http://jsperf.com/append-dom-elements-orphan-vs-document-fragment. Ironically, though, 2) is faster than 1) which contains no DOM fragments. So DOM fragments that occur dynamically are not a problem.
As a web/app developer, i would like to find any orphaned DOM fragment leaks so that I can properly optimize my JS code for least memory consumption.

Acceptance Criteria:
- DOM elements not attached to the DOM are broken off and above a certain lifetime threshold are highlighted
- able to distinguish DOM leaks from DOM fragments, since some DOM fragments are ok to have around as long as they are short lived.
- The relevant JS and DOM memory amounts are given
- JS References are shown
- Able to navigate to the code references

Note: this is a bit of a holy grail for perf management on HTML5 apps. This could also be done in "report" style, i.e. run some sort of analysis on the recording and report back. But I suspect it would be easier to relate events causally, i.e. find where the fragments break off, and see what code was executed shortly before. 

Note: DOM fragments are not bad in themselves, it's just if they hang around and keep growing that they become a problem. We have to find the ones that still have dangling JS references and don't get GC'd. See these simple tests that compare keeping the fragments around versus removing them: http://jsperf.com/create-dom-fragments. 

Expect that some research will need to go into this user story before it goes into implementation. 

Example test cases: http://jsperf.com/append-dom-elements-orphan-vs-document-fragment. Ironically, though, 2) is faster than 1) which contains no DOM fragments. So DOM fragments that occur dynamically are not a problem.
Flags: pm-scrub?
It seems to me that, when a detached DOM fragment is not GC'd, that must be because JS is holding onto it somehow. If that's the case, then we don't need to treat DOM fragments differently from other kinds of data structures JS might build --- it's just that, when web page JS builds a large detached data structure, it often happens to be a DOM fragment.

If that's so, then this specific story can be addressed with a more general tool. But certainly, we must ensure that the general tool addresses this story well.
Component: Developer Tools → Developer Tools: User Stories
User Story: (updated)
Component: Developer Tools: User Stories → Developer Tools: Memory
Flags: pm-scrub?
Product: Firefox → DevTools
I believe the current dominator view will find this, so I'll close this bug. Feel free to reopen with more information if you think otherwise !
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.