[maemo-developers] python2.5 - unnecessary multiple processes forked
From: Martin Grimme martin.grimme at gmail.comDate: Mon Dec 31 18:06:03 EET 2007
- Previous message: python2.5 - unnecessary multiple processes forked
- Next message: python2.5 - unnecessary multiple processes forked
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Especially make use of gc.collect() after you have worked with gdk.Pixbuf objects. They won't free their memory otherwise. It's a good habit to free unused Pixbufs with del and run the garbage collector afterwards. And be aware that if a class overrides the __del__ method (some sort of destructor), it won't be freed by the garbage collector at all. Cheers, Martin 2007/12/31, Alex Iliadis <alex at immunityinc.com>: > I recommend using the garbage collector module manually to override the > defaults. Python for some reason doesn't reclaim memory fast. So if you > put in your code: > import gc > gc.collect() (at the right spots, probably after the file chooser dialog > and after some memory intensive tasks). You should notice a lot of memory > being free'd up. > > -Alex > > On Sunday 30 December 2007 05:20:34 pm Jayesh Salvi wrote: > > Hi, > > > > I am porting a pygtk application to maemo. It works alright, but I > > noticed that it was consuming lot of memory, preventing me from opening > > other applications. > > > > When I investigated, I found that my python application was forking 4 > > more instances of itself, each one identical in memory footprint. Thus > > they consumed nearly 60-70% of my memory. > > > > So I ran my application using pdb and narrowed down to a code segment > > that was leading to multiple instances of the process. It turned out > > that when I call run() on hildon.fileChooserDialog object, the dialog > > opens and at that moment in the "top" I see 4 more instances being > > forked. > > > > I fail to understand this behavior. I replaced the hildon widgets by > > pure gtk widgets and I see similar behavior, except that 2 more > > instances get forked. Also when using gtk.FileChooserDialog, these new > > instances get created in the instantiation of the dialog object, rather > > than call to run(). (code included below) > > > > So to further explore the problem, I ran same application on my desktop > > with gtk widgets. But I verified that when fileChooserDialog's run is > > called, there are no additional instances of python. > > > > I am running this code on n770, with 2007 HE and python2.5 runtime. My > > application code is pure python and not using any additional libraries. > > In fact following would be a simpler version of it to reproduce the > > problem: > > > > import gtk > > import hildon > > > > #window = gtk.Window(gtk.WINDOW_TOPLEVEL) > > > > #fileChooser = gtk.FileChooserDialog( > > # title="Choose a photo to publish", > > # buttons=(gtk.STOCK_CANCEL, gtk.RESPONSE_CANCEL, > > # gtk.STOCK_OK, gtk.RESPONSE_OK)) > > > > fileChooser = hildon.FileChooserDialog( > > window,gtk.FILE_CHOOSER_ACTION_OPEN) > > > > > > result = fileChooser.run() > > > > if result == gtk.RESPONSE_OK: > > print fileChooser.get_filename() > > > > Do you have any tips, as to what might be going wrong? > > > > This problem is fatal at least on n770 - it will trigger low memory > > message when other applications are used on the side. > > > > Any help will be useful. > > > > Thanks, > > > _______________________________________________ > maemo-developers mailing list > maemo-developers at maemo.org > https://lists.maemo.org/mailman/listinfo/maemo-developers >
- Previous message: python2.5 - unnecessary multiple processes forked
- Next message: python2.5 - unnecessary multiple processes forked
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]