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
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 [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
ext Frantisek Dufka [EMAIL PROTECTED] writes:
I can't
imagine any valid reason for gtk/hildon to fork more processes just to
show a GUI dialog. Does anyone know?
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
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
Hi,
don't believe everything that 'top' tells you. :)
'top' on Linux also lists threads as standalone processes, thus giving
the illusion of wasting lots of memory. If the entries show exactly
the same amount of memory, then you can often assume that they share
the same amount of memory.
On 12/30/07, Jayesh Salvi [EMAIL PROTECTED] 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
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
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
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.
Jayesh Salvi wrote:
I can't
imagine any valid reason for gtk/hildon to fork more processes just to
show a GUI dialog. Does anyone know?
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.)
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
On 12/31/07, Jayesh Salvi [EMAIL PROTECTED] 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
Jayesh Salvi wrote:
I guess there isn't much to do - for an app programmer at least. I found
the same behavior with osso_pdfviewer. It also uses hildon's
FileChooserDialog. But even before that dialog is invoked, multiple
processes are forked. ... and they do not disappear until their
forgot to cc the list.
On 12/31/07, Jayesh Salvi [EMAIL PROTECTED] wrote:
BTW, are you sure the memory situation is really worse because of this?
What I see is, in 'top' all these processes show same percentage of memory
utilization under %MEM column (17% or so for each of them). I am
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
16 matches
Mail list logo
