[maemo-developers] python2.5 - unnecessary multiple processes forked

[From: Jayesh Salvi]

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.

On 1/3/08, Jayesh Salvi <jayesh at altfrequency.com> wrote:
>
> 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.
>
> 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 plugins<http://code.google.com/p/altcanvas/wiki/GimpPublishr>.
> Now I am putting the same code on maemo. I will soon release a .deb file
> once I iron out some wrinkles.
>
> Thanks,
> Jayesh
>
> On 1/2/08, Eero Tamminen <eero.tamminen at nokia.com> wrote:
> >
> > Hi,
> >
> > ext Jayesh Salvi wrote:
> > >> I'm not sure but think it is because of gnome-vfs. Don't know proper
> > >> terminology but maybe each vfs 'provider' in the dialog (like mmc,
> > phone
> > >> etc.) starts new process or something like that.
> > >>
> > >> That sounds correct. I experimented with other dialogs that do no
> > involve
> > > filesystem access (NamePasswordDialog, SortDialog), and they do not
> > fork any
> > > extra processes.
> >
> > They are not processes, but gnome-vfs worker threads
> > (you don't want the UI to freeze e.g. until network timeouts).
> >
> >
> > > So this behavior seems valid for FileChooserDialog. But then I should
> > be
> > > able to cleanup those extra processes when I am done with the
> > > FileChooserDialog. I called destroy() on the dialog object, but that
> > doesn't
> > > help.
> >
> > They remain in the gnome-vfs thread pool even after the UI component
> > is destroyed.
> >
> > The memory usage issue is elsewhere.  You could look into your
> > program Private_Dirty memory usage in /proc/PID/smaps file.
> > Or run the same program on your PC under Valgrind Massif plugin:
> >         http://maemo.org/development/tools/doc/valgrind
> >         http://valgrind.org/docs/manual/ms-manual.html
> >
> > I'm not sure how well that tells about issues in Python code.
> > Is there any memory profiler for Python applications?
> >
> >
> >         - Eero
> >
>
>
>
> --
> ---
> Jayesh




-- 
---
Jayesh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.maemo.org/pipermail/maemo-developers/attachments/20080105/e292abee/attachment.htm