I found out that the sluggishness observed was because of the Microb engine. Last night when I tried by switching to Opera engine, it worked very fast. So it's not the multiple threads that hildon or GTK fork, that cause performance issues.
<br><br><div><span class="gmail_quote">On 1/3/08, <b class="gmail_sendername">Jayesh Salvi</b> <<a href="mailto:jayesh@altfrequency.com">jayesh@altfrequency.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;">
Thanks for all the info. I am planning to run the FileChooserDialog in a different process than my rest of the app. That may sound weird, but it fits my application's context alright. My pygtk app will run as a service, so that it can be invoked by other applications as well. FileChooserDialog is just one entry point into my app.
<br><br>Detail of my app if you are interested: It is a pygtk GUI that lets you upload images to Flickr or Picasaweb. I have already published the code as Gimp, Inkscape <a href="http://code.google.com/p/altcanvas/wiki/GimpPublishr" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
plugins</a>. Now I am putting the same code on maemo. I will soon release a .deb file once I iron out some wrinkles.<br><br>Thanks,<br>Jayesh<div><span class="e" id="q_1173edfe593e34bc_1"><br><br><div><span class="gmail_quote">
On 1/2/08, <b class="gmail_sendername">Eero Tamminen
</b> <<a href="mailto:eero.tamminen@nokia.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">eero.tamminen@nokia.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;">
Hi,<br><br>ext Jayesh Salvi wrote:<br>>> I'm not sure but think it is because of gnome-vfs. Don't know proper<br>>> terminology but maybe each vfs 'provider' in the dialog (like mmc, phone<br>
>> etc.) starts new process or something like that.
<br>>><br>>> That sounds correct. I experimented with other dialogs that do no involve<br>> filesystem access (NamePasswordDialog, SortDialog), and they do not fork any<br>> extra processes.<br><br>They are not processes, but gnome-vfs worker threads
<br>(you don't want the UI to freeze e.g. until network timeouts).<br><br><br>> So this behavior seems valid for FileChooserDialog. But then I should be<br>> able to cleanup those extra processes when I am done with the
<br>> FileChooserDialog. I called destroy() on the dialog object, but that doesn't<br>> help.<br><br>They remain in the gnome-vfs thread pool even after the UI component<br>is destroyed.<br><br>The memory usage issue is elsewhere. You could look into your
<br>program Private_Dirty memory usage in /proc/PID/smaps file.<br>Or run the same program on your PC under Valgrind Massif plugin:<br> <a href="http://maemo.org/development/tools/doc/valgrind" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
http://maemo.org/development/tools/doc/valgrind
</a><br> <a href="http://valgrind.org/docs/manual/ms-manual.html" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://valgrind.org/docs/manual/ms-manual.html</a><br><br>I'm not sure how well that tells about issues in Python code.
<br>Is there any memory profiler for Python applications?
<br><br><br> - Eero<br></blockquote></div><br><br clear="all"><br></span></div>-- <br>---<br><span class="sg">Jayesh
</span></blockquote></div><br><br clear="all"><br>-- <br>---<br>Jayesh