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