Why doesn't tkinter release memory when an instance is destroyed?

When you create an instance of Tk, you are creating more than just a widget. You are creating an object that has several attributes (an embedded tcl interpreter, a list of widgets, etc). When you do root.destroy(), you're only destroying some of the data owned by that object. The object itself still exists and takes up memory. Since you keep a reference to that object in a list, that object never gets garbage-collected so the memory hangs around.

When you create a root window with root = tk.Tk(), you get back an object (root). If you look at the attributes of that object with vars, you see the following:

>>> root = tk.Tk()>>> vars(root){'children': {}, '_tkloaded': 1, 'master': None, '_tclCommands': ['tkerror', 'exit', '4463962184destroy'], 'tk': <_tkinter.tkapp object at 0x10a1d7f30>}

When you call root.destroy(), you are only destroying the widget itself (essentially, the elements in the _tclCommands list). The other parts of the object remain intact.

>>> root.destroy()>>> vars(root){'children': {}, '_tkloaded': 1, 'master': None, '_tclCommands': None, 'tk': <_tkinter.tkapp object at 0x10a1d7f30>}

Notice how _tclCommands has been set to None, but the rest of the attributes are still taking up memory. One of those, tk takes up a fair amount of memory that never gets reclaimed.

To completely remove the object, you need to delete it. In your case you need to remove the item from the list so that there are no longer any references to the object. You can then wait for the garbage collector to work it's magic, or you can explicitly call the garbage collector.

This may not reclaim 100% of the memory, but it should get you pretty close.

All that being said, tkinter wasn't designed to be used this way. The underlying expectation is that you create a single instance of Tk at the start of your program, and keep that single instance alive until your program exits.

In your case I recommend you create the root window once at the start of the program, and hide it. You can then call askopenfile() as often as you like throughout your program. If you want something more general-purpose, create a function that creates the root window the first time it is called and caches the window so that it only has to create it once.

There are three issues here, one of which is tkinter's fault, one of which is yours, and one of which is behaving as intended.

The three issues are:

1. tkinter creates an undetectable reference cycle as part of registering its cleanup handlers, which is only broken by explicitly calling destroy (if you don't do so, the reference cycle is never cleaned, and the resources are held forever)
2. You're holding on to your Tk objects even after you destroy them
3. The small object heap is rarely, if ever, returned to the OS before program termination (the memory is kept around for future allocations)

Problem #1 means you must destroy any Tk you create explicitly if there is any chance of recovering the memory.

Problem #2 means that you must explicitly get rid of any reference to a Tk (after destroying it) before creating a new one if you want the memory to be available for other purposes. In some cases, you'd also want to explicitly set tk.NoDefaultRoot() to prevent the first Tk you create from being cached on tkinter as the default root (that said, explicit calls to destroy on such an object will clear the cached default root, so this isn't going to be a problem in many cases).

Issue #3 means you must get rid of the references eagerly, rather than waiting until the end of the program to delete your root list; if you wait until the end to delete it, yes, the memory will be returned to the heap, but not to the OS, so it will look like you're still using all of it. It's not a real problem though; the unused memory will be paged out to disk if the OS is in need of RAM (it usually pages idle pages before active ones), and keeping it around improves the performance of most code.

Specifically, it looks like the .tk attribute of Tk instances isn't being cleaned up even when you explicitly destroy the Tk instancde. You can cap the memory growth by changing your loop to get rid of the last reference to the Tk object, or if you just want to free the low level C resources, explicitly unlink .tk after destroying the new Tk element**:

# Not necessary, but avoids caching any Tk as a root when you don't want ittk.NoDefaultRoot()  root = []  # Missing in your original code, but I'm assuming it was a plain listfor i in range(20):    root.append(tk.Tk())    root[-1].destroy()    # Either drop the reference to the `Tk` completely:    root[-1] = None    # or just drop the reference to its C level worker object    root[-1].tk = None    # Optionally, call gc.collect() here to forcibly reclaim memory faster    # otherwise you're likely to see memory usage grow by a few KB as uncleaned    # cycles aren't reclaimed in time so we see phantom leaks (that would    # eventually be cleaned)    mem()

Explicitly clearing the reference allows the underlying resources to be cleaned, based on the output from my slightly modified script:

12,152,83217,539,07217,924,096  # At this point, the original code was above 18.8M bytes17,965,05617,965,056  # At this point, the original code was above 21.7M bytes... remains unchanged until end of program if gc.collect() called regularly ...

The fact that the memory is never completely reclaimed for the first object isn't surprising. Memory allocators rarely bother to actually return the memory to the operating system unless the allocation was huge (large enough to trigger a mode switch that makes an independent request to the OS for memory that is managed separately from the "small object heap"). Otherwise, they maintain a free list of memory that is no longer in use and can be reused.

The ~6 MB of "waste" here was likely a bunch of small allocations involved in creating the Tk object itself and the tree of objects it manages, that, while subsequently returned to the heap for reuse, will not be returned to the OS until the program exits (that said, if that part of the heap is never used again, the OS may preferentially page the unused parts out to disk if it runs low on memory). You can see how this optimization helped by noticing that the memory use stabilizes almost immediately; the new tk.Tk() objects are just reusing the same memory as the first once (the lack of complete stability is likely due heap fragmentation causing a need for small additional allocations).