Gabriel Genellina wrote: > En Sun, 20 May 2007 23:54:15 -0300, Jim Kleckner <[EMAIL PROTECTED]> > escribió: > >> I understand from the documentation that types with a finalizer method >> that participate in cycles can't be collected. > > Yes; older Python versions could not manage any kind of cycles, now only > objects with __del__ cause problems. > You can explicitely break the cycle (removing the reference, ensuring that > some finalization method is always called, maybe using try/finally) or you > may use weak references (by example, in a tree-like structure, a node > might hold a weak reference to its parent). > >> What is the best way to go about finding these cycles? >> Googling gives a variety of methods none of which seem terribly >> mainstream for such a common problem. > > Avoid them in the first place :) > Use the gc module: after a call to gc.collect(), see if something remains > in gc.garbage
I would have sworn that there were uncollectable objects when I tried this before. Now they don't show up. I guess that is good... Which leads to >> Object memory usage: >> >> Has anyone written a function to sweep out an object to discover how >> much memory it and all the objects it references is using? This would >> be great for performance tuning. > > A rough estimate may be the object's pickle size. But it's hard to measure > precisely; by example, strings are immutable and you may have thousands of > shared references to the same string, and they require just a few bytes > each. Good idea, thanks. I take it then that memory profiling isn't available? -- http://mail.python.org/mailman/listinfo/python-list
