in reply to Re^4: Tk, HLists and memory leakage
in thread Tk, HLists and memory leakage

No problem. I didn't get offended at all by your frustration. I remember the first time I got bit by HList's(and Tk's) memory gain problem. I spent about 2 weeks on something, figuring It was all ready to go, then I started watching the memory. Oh, the feeling in the pit of my stomach as I realized that 2 weeks was just ripped away from me. Thats why now, I check for memory gains with MeM, at every step in the development, to catch the problems before they get buried too deep in more code.

As a general rule however, whenever you choose to use objects in a create-destroy cycle, you will get memory gains. Alot has been written on it in nodes here, and basically it has something to do with the "ref count" of the widgets. That means that an object is never truly destroyed as long as there is at least 1 ref to it somewhere. Now the problem with HList (and Tk) is that they keep hard to find refs buried deep in their code. So it's almost impossible to get the ref count to go to zero, once you use an object as part of a widget. HList in particular, seems to keep an hidden internal counter of it's children. So say if you create 10 entries, they will be 0-10 on the internal counter. If you delete those 10, and create 10 more, the internal counter is 11-20. Refs to objects can hide in there.

So the safest procedure, is always design your programs to reuse all objects, never use the create-destroy cycle unless it's just a small short-lived program.


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