Opened 9 years ago

Closed 9 years ago

#16439 closed defect (wontfix)

TabContainer: memory leak

Reported by: JayZ(zhouxiang) Owned by: JayZ(zhouxiang)
Priority: undecided Milestone: tbd
Component: Dijit Version: 1.8.1
Keywords: Cc:
Blocked By: Blocking:


We've create a test case for tabContainer, and do the "add tab" and "close tab" action, repeat it in 50+ times, and will see 10+ Megabytes memory leak. Please refer to the "tabcontainer_leak.html" file (dojo1.8)

Attachments (1)

tabcontainer_leak.html (2.8 KB) - added by JayZ(zhouxiang) 9 years ago.

Download all attachments as: .zip

Change History (7)

Changed 9 years ago by JayZ(zhouxiang)

Attachment: tabcontainer_leak.html added


comment:1 Changed 9 years ago by bill

Component: GeneralDijit
Owner: set to JayZ(zhouxiang)
Status: newpending
Summary: memory leak in tabcontainerTabContainer: memory leak

OK. That's not necessarily a memory leak. The question is whether or not memory usage keeps going up, or levels off at 10+ megabytes. So it's a question of creating a program that continually adds and closes tabs (with maybe a 100ms delay after each cycle) and watch the pattern of memory usage.

Also, what browser did you see the leak on?

comment:2 Changed 9 years ago by JayZ(zhouxiang)

Status: pendingnew

the leak happens in IE8, FF and Chrome are fine.

comment:3 Changed 9 years ago by bill

Hmm OK. Well, there's no performance degradation compared to 1.6. After 50 iterations:

1.6: 59M --> 82M trunk: 68M --> 81M

I'll look at it some more, but I'm not surprised that memory goes up after creating and destroying 25000 widgets, and not sure if there will be any way to improve the performance.

comment:4 Changed 9 years ago by bill

PS: The dijit/form/Button widget is quite complicated in order to workaround layout issues in IE6 and IE7. Specifically, the visible button is a <span> which triggers a click event on a hidden <input>.

That surely has a cost associated with it and perhaps creating 100,000 event handlers is what's causing IE's memory usage to increase. If your actual issue is with dijit/form/Button then perhaps you should use a simpler button widget more like dojox/mobile/Button.

comment:5 Changed 9 years ago by JayZ(zhouxiang)

The issue in the real application include not only button widget, but also contentPane, form widgets, ... The widget number depends on the application context, but less than 100 widgets each time

comment:6 Changed 9 years ago by bill

Resolution: wontfix
Status: newclosed

I'm going to close this. The reporter said he solved the majority of his actual problem by "nulling out the reference to the tab widget", although I don't understand why that was necessary or what exactly he did.

But as for the actual memory increase in the supplied test case, there's nothing I know to improve the problem short of rearchitecting the button widget to be based on a <button> node, to avoid needing internal event handlers for each button instance. And that is difficult due to IE rendering glitches with <button> widgets with styling.

Note: See TracTickets for help on using tickets.