On Thu, Oct 9, 2008 at 12:12 AM, Federico Mena Quintero <[EMAIL PROTECTED]> wrote: > On Tue, 2008-10-07 at 18:26 +0200, Tomeu Vizoso wrote: > >> - Developed a tool for monitoring memory allocation inside the python >> interpreter. Code: >> http://dev.laptop.org/git?p=users/rlucchese/python-allocstatsmodule/.git;a=summary > > Nice, nice, nice! Is this something we could use for the bloaty python > thingies we have around in GNOME? :)
I think so, but plays a relatively small role in the whole profiling process. Most important is to remove leaks, that are unfortunately very common in Pygtk apps. About leak debugging of Pygtk apps, we have done as follows: == Look for actions in the UI that result in unbounded allocations == Use Riccardo's allocstats module to periodically print allocation stats, for example in an idle handler or a key event handler. When you find an UI action that results in net allocation every time the UI is returned to its previous state, note this UI action as leaky. == Remove all leaks from the python side using Guppy's heapy == Connect from another python shell session to the debugged process using heapy's monitor: http://guppy-pe.sourceforge.net/heapy_Use.html#heapykinds.Use.monitor Reset the heap to zero, perform the UI action, then print the heap. Find a class that makes sense from the application logic POV, then check why it's being hold in memory. Most probably will be because an instance belonging to the base state of the app is holding a reference to it. And the most common cause is because the shorter-lived object is listening on a signal from the longer-lived object. If the shorter-lived object is a widget, disconnect those signals in its destroy signal handler. http://guppy-pe.sourceforge.net/ http://gentooexperimental.org/~ferringb/heapy.rst http://blog.redinnovation.com/2008/03/07/debugging-django-memory-leak-with-trackrefs-and-guppy/ http://wiki.laptop.org/go/Memory_leak_testing == remove all leaks from the C GObject side using refdbg == If after removing all leaks from the python side, memory allocations continue to grow, then we have leaks in the C side, most probably on C code local to the app, which is presumably less debugged that Pygtk itself. Get refdbg, and use it as you would do with a normal Gtk app, check any instances that get referenced more than unreferenced and that should get released when the UI action finishes but doesn't. Then add an unref somewhere ;) http://refdbg.sourceforge.net/ Sorry this is so vague and improvised, we should do a proper HOWTO out of it, but time doesn't abound around here... HTH, Tomeu _______________________________________________ Sugar mailing list [email protected] http://lists.laptop.org/listinfo/sugar
