Re: [matplotlib-devel] Memory leaks
Eric Firing wrote: > I also made memleak_gui.py more flexible with arguments. For example, > here are tests with three backends, a generous number of loops, and > suppression of intermediate output: Those changes are really helpful. I just added code to display the total number of objects in the Python interpreter (len(gc.get_objects()) with each iteration as well, as that can be useful. (It doesn't rule out memory leaks, but if it is increasing, that is definitely a problem.) I also added a commandline option to print out any cycles involving uncollectable objects, and added the necessary function to do so to cbook.py. Cheers, Mike - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Memory leaks
Michael Droettboom wrote: > Eric Firing wrote: >> I also made memleak_gui.py more flexible with arguments. For example, >> here are tests with three backends, a generous number of loops, and >> suppression of intermediate output: > > Those changes are really helpful. I just added code to display the > total number of objects in the Python interpreter (len(gc.get_objects()) > with each iteration as well, as that can be useful. (It doesn't rule > out memory leaks, but if it is increasing, that is definitely a problem.) > > I also added a commandline option to print out any cycles involving > uncollectable objects, and added the necessary function to do so to > cbook.py. > > Cheers, > Mike Mike, Good, thank you. I just committed a change to the output formatting of memleak_gui so that if you redirect it to a file, that file can be loaded with pylab.load() in case you want to plot the columns. (At least this is true if you don't use the -c option.) Yesterday, before your commits, I compared memleak_gui with stock Python 2.4 versus stock 2.5 (both from ubuntu feisty) and found very little difference in the OS memory numbers. Eric - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Memory leaks
Eric Firing wrote: > > I just committed a change to the output formatting of memleak_gui so > that if you redirect it to a file, that file can be loaded with > pylab.load() in case you want to plot the columns. (At least this is > true if you don't use the -c option.) > Great. Sorry for stomping on that ;) > Yesterday, before your commits, I compared memleak_gui with stock > Python 2.4 versus stock 2.5 (both from ubuntu feisty) and found very > little difference in the OS memory numbers. Are they still increasing linearly? I'm still seeing some mystery leaks with Gtk, Qt4 and (much smaller) on Tk. Qt and Wx seem fine here. Unfortunately Qt4 crashes valgrind, so it's not of much use. I'm curious whether your results match that. I'm not terribly surprised that 2.4 isn't different from 2.5, since the case in which entire memory pools are freed in 2.5 is probably hard to trigger. Cheers, Mike - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Memory leaks
Michael Droettboom wrote: Eric Firing wrote: I just committed a change to the output formatting of memleak_gui so that if you redirect it to a file, that file can be loaded with pylab.load() in case you want to plot the columns. (At least this is true if you don't use the -c option.) Great. Sorry for stomping on that ;) Yesterday, before your commits, I compared memleak_gui with stock Python 2.4 versus stock 2.5 (both from ubuntu feisty) and found very little difference in the OS memory numbers. Are they still increasing linearly? I'm still seeing some mystery leaks with Gtk, Qt4 and (much smaller) on Tk. Qt and Wx seem fine here. Attached are runs with gtk, wx, qtagg, and tkagg. Quite a variety of results: tkagg is best, with only slow memory growth and a constant number of python objects; qtagg grows by 2.2k per loop, with no increase in python object count; wx (which is built on gtk) consumes 3.5k per loop, with an increasing object count; gtk consumes 1.8k per loop with an increasing object count. All runs are on stock ubuntu feisty python 2.5. Eric Unfortunately Qt4 crashes valgrind, so it's not of much use. I'm curious whether your results match that. I'm not terribly surprised that 2.4 isn't different from 2.5, since the case in which entire memory pools are freed in 2.5 is probably hard to trigger. Cheers, Mike # columns are: iteration, OS memory (k), number of python objects # 02742355194 102744455204 202744455214 302744455224 402748955234 502756655244 602756655254 702756655264 802756655274 902756655284 1002756655294 1102756655304 1202782255314 1302782255324 1402782255334 1502782255344 1602782255354 1702782255364 1802789755374 1902789755384 2002789755394 2102789755404 2202789755414 2302789755424 2402789755434 2502789755444 2602789755454 2702797255464 2802797255474 2902797255484 3002797255494 3102797255504 3202797255514 3302797255524 3402797255534 3502797255544 360279524 3702800955564 3802800955574 3902800955584 4002808755594 4102808755604 4202808755614 4302834355624 4402834355634 4502834355644 4602834355654 4702834355664 4802842455674 4902842455684 5002842455694 5102842455704 5202842455714 5302842455724 5402850555734 5502850555744 5602850555754 5702850555764 5802850555774 5902850555784 6002850555794 6102850555804 6202850555814 6302850555824 6402850555834 6502850555844 6602858055854 6702858055864 6802858055874 6902858055884 7002858055894 7102858055904 7202858055914 7302858055924 7402858055934 7502883655944 7602883655954 7702883655964 7802890055974 7902890055984 8002890055994 8102890056004 8202890056014 8302890056024 8402890056034 8502890056044 8602897056054 8702897056064 8802897056074 8902897056084 9002897056094 9102897056104 9202897056114 9302897056124 9402905256134 9502905256144 9602905256154 9702905256164 9802905256174 9902905256184 10002905256194 10102905256204 10202930856214 10302930856224 10402930856234 10502928656244 10602934056254 10702934056264 10802934056274 10902934056284 11002934056294 11102934056304 11202934056314 11302934056324 11402934056334 11502937356344 11602944156354 11702944156364 11802944156374 11902944156384 12002944156394 12102944156404 12202952056414 12302952056424 12402952056434 12502952056444 12602952056454 12702952056464 12802952056474 12902952056484 13002952056494 13102950356504 13202955356514 13302953256524 13402958256534 13502983856544 13602991856554 13702991856564 13802991856574 13902991856584 14002991856594 14102991856604 14202991856614 14302991856624 14402991856634 14502991856644 14602991856654 14702991856664 14802991856674 14902998856684 15002998856694 15102998856704 15202998856714 15302996656724 15402
Re: [matplotlib-devel] Memory leaks
On Tuesday 03 July 2007 04:33:46 pm Eric Firing wrote: > Michael Droettboom wrote: > > Eric Firing wrote: > >> I just committed a change to the output formatting of memleak_gui so > >> that if you redirect it to a file, that file can be loaded with > >> pylab.load() in case you want to plot the columns. (At least this is > >> true if you don't use the -c option.) > > > > Great. Sorry for stomping on that ;) > > > >> Yesterday, before your commits, I compared memleak_gui with stock > >> Python 2.4 versus stock 2.5 (both from ubuntu feisty) and found very > >> little difference in the OS memory numbers. > > > > Are they still increasing linearly? I'm still seeing some mystery leaks > > with Gtk, Qt4 and (much smaller) on Tk. Qt and Wx seem fine here. > > Attached are runs with gtk, wx, qtagg, and tkagg. Quite a variety of > results: tkagg is best, with only slow memory growth and a constant > number of python objects; qtagg grows by 2.2k per loop, with no increase > in python object count; wx (which is built on gtk) consumes 3.5k per > loop, with an increasing object count; gtk consumes 1.8k per loop with > an increasing object count. > > All runs are on stock ubuntu feisty python 2.5. > > Eric > > > Unfortunately Qt4 crashes valgrind, so it's not of much use. > > I'm curious whether your results match that. I'm not terribly surprised > > that 2.4 isn't different from 2.5, since the case in which entire memory > > pools are freed in 2.5 is probably hard to trigger. I am swamped at work, and have not been able to follow this thread closely. But I just updated from svn and ran memleak_gui.py with qt4: # columns are: iteration, OS memory (k), number of python objects # 03736453792 103744153792 203744153792 303752553792 403748353792 503751153792 603753953792 703756853792 803759653792 903762453792 1003765353792 # columns above are: iteration, OS memory (k), number of python objects # # uncollectable list: [] # # Backend Qt4Agg, toolbar toolbar2 # Averaging over loops 30 to 100 # Memory went from 37525k to 37653k # Average memory consumed per loop: 1.8286k bytes Darren - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
