Opened 6 years ago

Last modified 5 years ago

#9230 open bug

Recreating a dialog leaks memory

Reported by: rosenfeld Owned by:
Priority: minor Milestone: none
Component: ui.dialog Version: 1.10.2
Keywords: Cc:
Blocked by: Blocking:

Description

http://jsbin.com/ewukip/8

Take a heap profile before and after clicking the button that will recreate the dialog a hundred times. In my Chrome, it goes from 12.4MB to 13.1MB. The delta should be zero ideally, right?

Change History (6)

comment:1 Changed 6 years ago by Scott González

Resolution: worksforme
Status: newclosed

You're probably looking at the values too soon and not allowing time for garbage collection. I opened that page, started recording, and clicked the button four times. The first time, memory increased. The second time memory increased. I waited a bit and memory dropped. The third time, memory increased just a tiny bit, then memory dropped. The fourth time, memory increased again. I waited a bit then forced garbage collection and the memory use went right back to the original values.

Here's a screenshot of the memory usage: http://cl.ly/image/0D0r3G2r1c3k

Here are the starting and ending values from the counters:
Document Count: 2 - 2
DOM Node Count: 420 - 420
Event Listener Count: 29 - 29

comment:2 Changed 6 years ago by rosenfeld

I assumed their documentation was correct:

https://developers.google.com/chrome-developer-tools/docs/heap-profiling

"Are "dead" (unreachable) objects included in snapshots? No. Only reachable objects are included in snapshots. Also, taking a snapshot always starts with doing a GC."

comment:3 Changed 6 years ago by Scott González

Resolution: worksforme
Status: closedreopened

Hmm...that's interesting that the memory is increasing while the counts are staying the same.

comment:4 Changed 6 years ago by Scott González

Status: reopenedopen

This seems to be partly related to the code for the button pane, even though there are no buttons. The button pane code is also apparently a performance killer.

comment:5 Changed 6 years ago by rosenfeld

But I believe you're right. It stabilizes after some clicks. Maybe the memory increase is caused by Chrome optimizing some code.

comment:6 in reply to:  4 Changed 5 years ago by Jörn Zaefferer

Replying to scott.gonzalez:

This seems to be partly related to the code for the button pane, even though there are no buttons. The button pane code is also apparently a performance killer.

Can you elaborate on that? What's the problem with the button pane?

Note: See TracTickets for help on using tickets.