Re: python2.5 - unnecessary multiple processes forked

[Eero Tamminen]

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.
 >> 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

Re: python2.5 - unnecessary multiple processes forked

[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 <[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.
> 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 <[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




-- 
---
Jayesh
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: python2.5 - unnecessary multiple processes forked

[Jayesh Salvi]

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.
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 <[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

Re: python2.5 - unnecessary multiple processes forked

[Eero Tamminen]

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
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: python2.5 - unnecessary multiple processes forked

[Kalle Valo]

"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 (like mmc, phone 
> etc.) starts new process or something like that.

I think you are correct. I heard that some gnome-vfs plugins, for
example UPnP, start their own thread (or something like that).

But I'm a network guy, I know jack about our UI. So I might be wrong
here.

-- 
Kalle Valo
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: python2.5 - unnecessary multiple processes forked

[Martin Grimme]

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,
Martin


2007/12/31, Jayesh Salvi <[EMAIL PROTECTED]>:
> 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 not sure if
> this is virtual memory or physical memory.
> >
> > My application logic flow goes like this: It gets the filename from the
> user (hence FileChooserDialog) and after some processing it has to open a
> URL in the browser. It sends an RPC request to the browser. What I am
> observing is, the browser takes a long time to open that URL and by the time
> it has opened it, my app gets killed without any error message. Once I had
> seen a low memory message during this process, but now my parent app gets
> killed without any such message.
> >
> > I am still trying to establish if the above behavior is only because of
> memory over consumption. I will update as I make progress.
> >
> > --
> > ---
> > Jayesh
>
>
>
> --
> ---
> Jayesh
> ___
> maemo-developers mailing list
> maemo-developers@maemo.org
> https://lists.maemo.org/mailman/listinfo/maemo-developers
>
>
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: python2.5 - unnecessary multiple processes forked

[Jayesh Salvi]

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 not sure if
> this is virtual memory or physical memory.
>
> My application logic flow goes like this: It gets the filename from the
> user (hence FileChooserDialog) and after some processing it has to open a
> URL in the browser. It sends an RPC request to the browser. What I am
> observing is, the browser takes a long time to open that URL and by the time
> it has opened it, my app gets killed without any error message. Once I had
> seen a low memory message during this process, but now my parent app gets
> killed without any such message.
>
> I am still trying to establish if the above behavior is only because of
> memory over consumption. I will update as I make progress.
>
> --
> ---
> Jayesh




-- 
---
Jayesh
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: python2.5 - unnecessary multiple processes forked

[Frantisek Dufka]

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 parent 
> exits.

I think once they are initialized they don't go away since you may 
actually need them if user clicks some file in the dialog which is 
'provided' by them.

> They keep occupying the same amount of memory as their parent. 
> This is really taxing on my n770.
> 
> If this is the default behavior of gnome-vfs based GTK apps, then I hope 
> it gets improved for embedded devices.
> 

BTW, are you sure the memory situation is really worse because of this? 
If yes then maybe this is specific to python. In C forked process does 
not add much memory overhead because memory pages in childs are shared 
with the parent until they are modified. So I guess when programming in 
C this is not a big issue so nobody cared so far.

Frantisek
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: python2.5 - unnecessary multiple processes forked

[Jayesh Salvi]

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 other dialogs that do no
> involve filesystem access (NamePasswordDialog, SortDialog), and they do not
> fork any extra processes.
>
> 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.


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 parent exits. They keep occupying the
same amount of memory as their parent. This is really taxing on my n770.

If this is the default behavior of gnome-vfs based GTK apps, then I hope it
gets improved for embedded devices.



-- 
> ---
> Jayesh




-- 
---
Jayesh
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: python2.5 - unnecessary multiple processes forked

[Jayesh Salvi]

>
> 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.

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.


-- 
---
Jayesh
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: python2.5 - unnecessary multiple processes forked

[Frantisek Dufka]

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.) starts new process or something like that.

Frantisek
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: python2.5 - unnecessary multiple processes forked

[Jayesh Salvi]

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. Does
anyone know?

On 12/31/07, Martin Grimme <[EMAIL PROTECTED]> wrote:
>
> 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), it won't be freed by the garbage collector at all.
>
>
> Cheers,
> Martin
>
> 2007/12/31, Alex Iliadis <[EMAIL PROTECTED]>:
> > 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 notice a lot of
> memory
> > being free'd up.
> >
> > -Alex
> >
> > On Sunday 30 December 2007 05:20:34 pm Jayesh Salvi 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 instances of itself, each one identical in memory footprint. Thus
> > > they consumed nearly 60-70% of my memory.
> > >
> > > So I ran my application using pdb and narrowed down to a code segment
> > > that was leading to multiple instances of the process. It turned out
> > > that when I call run() on hildon.fileChooserDialog object, the dialog
> > > opens and at that moment in the "top" I see 4 more instances being
> > > forked.
> > >
> > > I fail to understand this behavior. I replaced the hildon widgets by
> > > pure gtk widgets and I see similar behavior, except that 2 more
> > > instances get forked. Also when using gtk.FileChooserDialog, these new
> > > instances get created in the instantiation of the dialog object,
> rather
> > > than call to run(). (code included below)
> > >
> > > So to further explore the problem, I ran same application on my
> desktop
> > > with gtk widgets. But I verified that when fileChooserDialog's run is
> > > called, there are no additional instances of python.
> > >
> > > I am running this code on n770, with 2007 HE and python2.5 runtime. My
> > > application code is pure python and not using any additional
> libraries.
> > > In fact following would be a simpler version of it to reproduce the
> > > problem:
> > >
> > > import gtk
> > > import hildon
> > >
> > > #window = gtk.Window(gtk.WINDOW_TOPLEVEL)
> > >
> > > #fileChooser = gtk.FileChooserDialog(
> > > #   title="Choose a photo to publish",
> > > #   buttons=(gtk.STOCK_CANCEL, gtk.RESPONSE_CANCEL,
> > > #   gtk.STOCK_OK, gtk.RESPONSE_OK))
> > >
> > > fileChooser = hildon.FileChooserDialog(
> > > window,gtk.FILE_CHOOSER_ACTION_OPEN)
> > >
> > >
> > > result = fileChooser.run()
> > >
> > > if result == gtk.RESPONSE_OK:
> > > print fileChooser.get_filename()
> > >
> > > Do you have any tips, as to what might be going wrong?
> > >
> > > This problem is fatal at least on n770 - it will trigger low memory
> > > message when other applications are used on the side.
> > >
> > > Any help will be useful.
> > >
> > > Thanks,
> >
> >
> > ___
> > maemo-developers mailing list
> > maemo-developers@maemo.org
> > https://lists.maemo.org/mailman/listinfo/maemo-developers
> >
> ___
> maemo-developers mailing list
> maemo-developers@maemo.org
> https://lists.maemo.org/mailman/listinfo/maemo-developers
>



-- 
---
Jayesh
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: python2.5 - unnecessary multiple processes forked

[Martin Grimme]

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), it won't be freed by the garbage collector at all.


Cheers,
Martin

2007/12/31, Alex Iliadis <[EMAIL PROTECTED]>:
> 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 notice a lot of memory
> being free'd up.
>
> -Alex
>
> On Sunday 30 December 2007 05:20:34 pm Jayesh Salvi 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 instances of itself, each one identical in memory footprint. Thus
> > they consumed nearly 60-70% of my memory.
> >
> > So I ran my application using pdb and narrowed down to a code segment
> > that was leading to multiple instances of the process. It turned out
> > that when I call run() on hildon.fileChooserDialog object, the dialog
> > opens and at that moment in the "top" I see 4 more instances being
> > forked.
> >
> > I fail to understand this behavior. I replaced the hildon widgets by
> > pure gtk widgets and I see similar behavior, except that 2 more
> > instances get forked. Also when using gtk.FileChooserDialog, these new
> > instances get created in the instantiation of the dialog object, rather
> > than call to run(). (code included below)
> >
> > So to further explore the problem, I ran same application on my desktop
> > with gtk widgets. But I verified that when fileChooserDialog's run is
> > called, there are no additional instances of python.
> >
> > I am running this code on n770, with 2007 HE and python2.5 runtime. My
> > application code is pure python and not using any additional libraries.
> > In fact following would be a simpler version of it to reproduce the
> > problem:
> >
> > import gtk
> > import hildon
> >
> > #window = gtk.Window(gtk.WINDOW_TOPLEVEL)
> >
> > #fileChooser = gtk.FileChooserDialog(
> > #   title="Choose a photo to publish",
> > #   buttons=(gtk.STOCK_CANCEL, gtk.RESPONSE_CANCEL,
> > #   gtk.STOCK_OK, gtk.RESPONSE_OK))
> >
> > fileChooser = hildon.FileChooserDialog(
> > window,gtk.FILE_CHOOSER_ACTION_OPEN)
> >
> >
> > result = fileChooser.run()
> >
> > if result == gtk.RESPONSE_OK:
> > print fileChooser.get_filename()
> >
> > Do you have any tips, as to what might be going wrong?
> >
> > This problem is fatal at least on n770 - it will trigger low memory
> > message when other applications are used on the side.
> >
> > Any help will be useful.
> >
> > Thanks,
>
>
> ___
> maemo-developers mailing list
> maemo-developers@maemo.org
> https://lists.maemo.org/mailman/listinfo/maemo-developers
>
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: python2.5 - unnecessary multiple processes forked

[Alex Iliadis]

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 notice a lot of memory 
being free'd up.

-Alex

On Sunday 30 December 2007 05:20:34 pm Jayesh Salvi 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 instances of itself, each one identical in memory footprint. Thus
> they consumed nearly 60-70% of my memory.
>
> So I ran my application using pdb and narrowed down to a code segment
> that was leading to multiple instances of the process. It turned out
> that when I call run() on hildon.fileChooserDialog object, the dialog
> opens and at that moment in the "top" I see 4 more instances being
> forked.
>
> I fail to understand this behavior. I replaced the hildon widgets by
> pure gtk widgets and I see similar behavior, except that 2 more
> instances get forked. Also when using gtk.FileChooserDialog, these new
> instances get created in the instantiation of the dialog object, rather
> than call to run(). (code included below)
>
> So to further explore the problem, I ran same application on my desktop
> with gtk widgets. But I verified that when fileChooserDialog's run is
> called, there are no additional instances of python.
>
> I am running this code on n770, with 2007 HE and python2.5 runtime. My
> application code is pure python and not using any additional libraries.
> In fact following would be a simpler version of it to reproduce the
> problem:
>
> import gtk
> import hildon
>
> #window = gtk.Window(gtk.WINDOW_TOPLEVEL)
>
> #fileChooser = gtk.FileChooserDialog(
> #   title="Choose a photo to publish",
> #   buttons=(gtk.STOCK_CANCEL, gtk.RESPONSE_CANCEL,
> #   gtk.STOCK_OK, gtk.RESPONSE_OK))
>
> fileChooser = hildon.FileChooserDialog(
> window,gtk.FILE_CHOOSER_ACTION_OPEN)
>
>
> result = fileChooser.run()
>
> if result == gtk.RESPONSE_OK:
> print fileChooser.get_filename()
>
> Do you have any tips, as to what might be going wrong?
>
> This problem is fatal at least on n770 - it will trigger low memory
> message when other applications are used on the side.
>
> Any help will be useful.
>
> Thanks,


___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: python2.5 - unnecessary multiple processes forked

[Lauro Moura]

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
> instances of itself, each one identical in memory footprint. Thus they
> consumed nearly 60-70% of my memory.
>
> So I ran my application using pdb and narrowed down to a code segment that
> was leading to multiple instances of the process. It turned out that when I
> call run() on hildon.fileChooserDialog object, the dialog opens and at that
> moment in the "top" I see 4 more instances being forked.
>
> I fail to understand this behavior. I replaced the hildon widgets by pure
> gtk widgets and I see similar behavior, except that 2 more instances get
> forked. Also when using gtk.FileChooserDialog, these new instances get
> created in the instantiation of the dialog object, rather than call to
> run(). (code included below)
>
> So to further explore the problem, I ran same application on my desktop with
> gtk widgets. But I verified that when fileChooserDialog's run is called,
> there are no additional instances of python.
>
> I am running this code on n770, with 2007 HE and python2.5 runtime. My
> application code is pure python and not using any additional libraries. In
> fact following would be a simpler version of it to reproduce the problem:
>
> ...
> Do you have any tips, as to what might be going wrong?
>

With the following C code[1] the same problem happens.

[1] http://pastebin.com/m2d7c9783

-- 
Lauro Moura
INdT - Instituto Nokia de Tecnologia
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

python2.5 - unnecessary multiple processes forked

[Jayesh Salvi]

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. Thus they
consumed nearly 60-70% of my memory.

So I ran my application using pdb and narrowed down to a code segment that
was leading to multiple instances of the process. It turned out that when I
call run() on hildon.fileChooserDialog object, the dialog opens and at that
moment in the "top" I see 4 more instances being forked.

I fail to understand this behavior. I replaced the hildon widgets by pure
gtk widgets and I see similar behavior, except that 2 more instances get
forked. Also when using gtk.FileChooserDialog, these new instances get
created in the instantiation of the dialog object, rather than call to
run(). (code included below)

So to further explore the problem, I ran same application on my desktop with
gtk widgets. But I verified that when fileChooserDialog's run is called,
there are no additional instances of python.

I am running this code on n770, with 2007 HE and python2.5 runtime. My
application code is pure python and not using any additional libraries. In
fact following would be a simpler version of it to reproduce the problem:

import gtk
import hildon

#window = gtk.Window(gtk.WINDOW_TOPLEVEL)

#fileChooser = gtk.FileChooserDialog(
#   title="Choose a photo to publish",
#   buttons=(gtk.STOCK_CANCEL, gtk.RESPONSE_CANCEL,
#   gtk.STOCK_OK, gtk.RESPONSE_OK))

fileChooser = hildon.FileChooserDialog(
window,gtk.FILE_CHOOSER_ACTION_OPEN)


result = fileChooser.run()

if result == gtk.RESPONSE_OK:
print fileChooser.get_filename()

Do you have any tips, as to what might be going wrong?

This problem is fatal at least on n770 - it will trigger low memory message
when other applications are used on the side.

Any help will be useful.

Thanks,
-- 
---
Jayesh
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers