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 r
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:
>
> Th
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
j
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 n
"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
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.
Cheers,
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
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 pa
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 experime
>
> 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 (Nam
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.) sta
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.
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 destructor),
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 should
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
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 footprint
16 matches
Mail list logo