#9230 open bug ()

Opened April 16, 2013 01:13PM UTC

Last modified September 30, 2013 10:46AM UTC

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?

Attachments (0)

Change History (6)

Changed April 16, 2013 01:32PM UTC by scottgonzalez comment:1

resolution:	→ worksforme
status:	new → closed

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

Changed April 16, 2013 01:37PM UTC by rosenfeld comment:2

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."

Changed April 16, 2013 02:08PM UTC by scottgonzalez comment:3

resolution:	worksforme
status:	closed → reopened

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

Changed April 16, 2013 02:14PM UTC by scottgonzalez comment:4

status:	reopened → open

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.

Changed April 16, 2013 02:17PM UTC by rosenfeld comment:5

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

Changed September 30, 2013 10:46AM UTC by jzaefferer comment:6

Replying to [comment:4 scott.gonzalez]: