On 7/10/06, Frantisek Dufka <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
MSN: [EMAIL PROTECTED]
ICQ#: 17249123
Skype: gsbarbieri
Mobile: +55 (81) 9927 0010
Phone: +1 (347) 624 6296; [EMAIL PROTECTED]
GPG: 0xB640E1A2 @ wwwkeys.pgp.net
_______________________________________________
maemo-developers mailing list
[email protected]
https://maemo.org/mailman/listinfo/maemo-developers
