in reply to Re^2: Memory leak
in thread Memory leak

Does destroying a widget not return all memory from them and their children? Is that my problem, or something else?

That's your problem. I was burned by the same thing when I built my first "big-long-running" script. If there is one rule I can summarize...you have to REUSE all widgets in Tk, or there will be leaks. Somewhere deep down in the innards of Tk, references to all objects are kept, and not released until the end of the program. I know it is a pain to deal with, but once you learn the tricks, it isn't too bad.

For instance, you say you open a fair number of windows, then destroy them....that is memory use going up. What you want to do, is pre-create a set of reusable top-level windows, each packed with the widgets they need (which will also be reused), and "withdraw" them. Now, when you need to load them with data, loop through them all, and "configure" each of them with the new data, then "raise" the toplevel. When you are done, don't destroy the toplevel, just "withdraw" it. When you need the next toplevel, just loop through the withdrawn toplevel(and it's widgets) and "reconfigure" them with the new data, then "raise" them again.

I have made some big programs run this way, loading, unloading, and reloading data, without memory leaks. The memory will increase to the size of the largest "instance" of the toplevel, but will be reused, and generally will level out at some average value.

Photo objects can be "emptied" with $photo->blank, text widgets can be blanked with $text->delete('1.0', 'end'); etc, etc.

I've found almost all widgets can be reused, without leaking, with the exception of the Progressbar.

Most Tk apps are small, and tend to do something then exit; so the small memory gains, created by using "destroy", can be ignored. But long running scripts have to be caarefully planned.

I'm not really a human, but I play one on earth. flash japh

Replies are listed 'Best First'.
Re^4: Memory leak
by aplonis (Pilgrim) on Jan 14, 2005 at 18:11 UTC

    Thank you, that would certainly explain it as a couple of the top-level windows get dragged to full-screen. And I've been destroy-ing those regularly. Sometimes I automate the whole sequence for many a file so that destroy might happen a hundred times. A couple of times I thought I'd crashed the OS...with 4GB...but now that I recall it seems as if only X-windows had locked. So it's the GUI not the OS which crashed, I guess.

    This withdraw and re-configure business does sound quite a pain to deal with...ex-post-facto...as now I must do. But I'll start chipping away at it.

    Thank you again,

    Gan

[reply]
[d/l]
[select]
      I learned the hard way too( which is why I havn't forgot :-) ). But the rewrite went pretty easy, since most of the logic was already thought out, and it was just changing the way things get displayed. Also, your next project will be alot easier, since you will know this from the beginning, and design accordingly.

      You think "what boxes" am I going to be displaying to the screen"? Then put them into hashes to make them easy to loop thru, like: 

      my %toplevel_1;
my %toplevel_2;

....
...
$toplevel_1{'label'} = $tl_1->Label(..etc);
$toplevel_1{'text'} = $tl_1->Text(..etc);


$toplevel_1{'label'}->configure(-text => $new_text);
$toplevel_1{'text'}->delete('1.0','end');

      [download]
      I'm not really a human, but I play one on earth. flash japh
[reply]
[d/l]

In Section Seekers of Perl Wisdom