Hi,
ext Jayesh Salvi wrote:
> On 1/3/08, Jayesh Salvi <[EMAIL PROTECTED]> 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.
> 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.
You could also try disabling Flash from the Browser to see whether it
helps.
- Eero
>>
>> Thanks,
>> Jayesh
>>
>> On 1/2/08, Eero Tamminen <[EMAIL PROTECTED]> 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
>
>
>
>
_______________________________________________
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
