[maemo-developers] python Re: [maemo-developers] Maemo 2.0 final release available

[From: Gustavo Sverzut Barbieri]

On 7/10/06, Frantisek Dufka <dufkaf at seznam.cz> wrote:
> Tommi Komulainen wrote:
> > On Fri, 2006-07-07 at 22:16 -0300, ext Gustavo Sverzut Barbieri wrote:
> >> I also know about that... but I want to know from Nokia guys if they
> >> expect someday to get it included by default, and if yes, what's the
> >> showstopper so far... if it's the size, how many megabytes would be
> >> ok?
> >
> > Can't discuss product features, but personally I'd guess when the
> > tradeoffs in writing applications in python are more beneficial than
> > writing them with C/C++. Basically you'd need at least one application
> > written in python shipping with the devices or software updates to
> > warrant including python by default.
> >
> > I haven't been following the python progress too closely, but I believe
> > the current issues are:
> >      1. horrible startup time
> >      2. memory consumption
> >      3. flash consumption?
> >      4. run-time speed?
> > (And I can imagine we could help startup time by sacrificing memory.)
>
> As for the horrible startup time even applications written in C start
> slowly but python is really much worse. Yesterday I tried the runtime in
> 2.0 repository with simple examples copied from
> http://www.maemo.org/platform/docs/pymaemo/python_maemo_howto.html and
> it is not very usable in current state. Those simple hello world apps
> start  approx. 4 seconds for the first time when python is not in file
> cache and approx. 2 seconds for second time. This is too much to be
> usable IMHO.

Yes.

But the 2 seconds for the second time is already better if you try
pygtk from CVS.

Problem is: Glib/GObject is actually a dynamic type system. Every call
to GTK_IS_WIDGET() will actually use the gtype system, that will call
gtk_$CLASS_type() to get the registered number for this type.

When you do write code in C, it will evaluate gtk_$CLASS_type() just
for used classes. But for PyGTK, it used to evaluate this for _EVERY_
class available, doing a lot of branches, function calls, memory
allocation, ... This seems to be fixed in PyGTK CVS with "lazy
evaluation" patch.

Anyway, it still take a lot of time and my guess is the size/number of
symbols of _gtk.so.


> There is also other feature/bug in those examples - they need to be
> killed with ctrl-c, they don't quit properly when closed via X button.
> Window is closed but application doesn't terminate in shell. Is this bug
> or some 'python caching for speedup' feature? I wouldn't like python to
> be cached in memory indefinitely.

So far there is no optimization of this kind.
I do plan to write a pythonserver, in the same fashion as wineserver
or kdeinit. A process that would link to _gtk.so and _hildon.so, when
you use python (in client form) it would just call the server and it
will fork() (sure, doing the right thing for stdin/stdout). However
this is not done at the moment.


>   When timing the example
> http://www.maemo.org/platform/docs/pymaemo/python_maemo_howto.html#Hildon+Program+Class
> with gtk.main() commented (so it exits after startup) it takes 5 seconds
> ~ $ time ./test.py
> real    0m 5.20s
> user    0m 2.60s
> sys     0m 2.11s
>
> when added "import time" and  "print time.time()"
> on the beginning before modules are loaded and in main around hildon usage
> if __name__ == "__main__":
>      print time.time()
>      app = HelloWorldApp()
>      app.run()
>      print time.time()
>
> it prints:
> ~ $  date +%s ; time ./test.py ; date +%s
> 1152527542
> 1152527543.54
> 1152527546.33
> 1152527547.27
> real    0m 4.88s
> user    0m 2.50s
> sys     0m 2.03s
> 1152527547
>
>
> BTW I also played with prelink (available in 2.0 repository). Seems like
> firmware image is not prelinked but I admit I didn't notice any speedup
> or memory gain when everything is prelinked. It has probably something
> to do with the fact that every UI executable is symlinked to
> osso-launcher so this looks like same trick used in KDE. But at least
> prelink does not hurt.

Yes, it may help... but what would help a lot is something like kdeinit.


-- 
Gustavo Sverzut Barbieri
--------------------------------------
Jabber: barbieri at gmail.com
   MSN: barbieri at gmail.com
  ICQ#: 17249123
 Skype: gsbarbieri
Mobile: +55 (81) 9927 0010
 Phone:  +1 (347) 624 6296; 08122692 at sip.stanaphone.com
   GPG: 0xB640E1A2 @ wwwkeys.pgp.net