Re: python Re: [maemo-developers] Maemo 2.0 final release available
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 real0m 5.20s user0m 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 real0m 4.88s user0m 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 maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: python Re: [maemo-developers] Maemo 2.0 final release available
On 7/10/06, Frantisek Dufka [EMAIL PROTECTED] wrote: 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. Are you talking about something that happens for every class, or just during library initialization? Either way, I'd love to see the patch, if you have a URL. Anyway, it still take a lot of time and my guess is the size/number of symbols of _gtk.so. Yeah, wrappers add symbols, and symbols increase load time and code size. I've made some not-often-used API optional in the gtkmm build to reduce this slightly. This is a fairly well known problem in the embedded world that is often masked with splash screens. Many companies still seem to prefer the plus of higher-level languages to the minus of longer load time. And maybe someone will come up with a faster symbol resolver/ABI/file-format one day. [snip] Murray Cumming [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: python Re: [maemo-developers] Maemo 2.0 final release available
On Mon, 2006-07-10 at 09:29 -0300, ext Gustavo Sverzut Barbieri wrote: On 7/10/06, Frantisek Dufka [EMAIL PROTECTED] wrote: 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. Oh, it's only 4 seconds. I was under the impression it would be closer to 10. It's not *that* bad then :) 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. Ouch! Another contributing factor is probably the number of local symbols in _gtk.so that need to be relocated. 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. We have maemo-launcher :) https://stage.maemo.org/svn/maemo/projects/haf/trunk/maemo-launcher/ Or, assuming that 95% of the time python on 770 would be used for GUI applications (rather than daemons, scripts or such) linking pygtk and pyhildon statically with python might be wortwhile optimization. Licenses permitting, of course. -- Tommi Komulainen[EMAIL PROTECTED] ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: python Re: [maemo-developers] Maemo 2.0 final release available
On 7/10/06, Murray Cumming [EMAIL PROTECTED] wrote:
On 7/10/06, Frantisek Dufka [EMAIL PROTECTED] wrote:
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.
Are you talking about something that happens for every class, or just
during library initialization? Either way, I'd love to see the patch, if
you have a URL.
PyGTK used to force calls to gtk_$CLASS_type() even for unused class,
during initialization.
About URL, they still use CVS, so there is not a snapshot about it
all... you may base your view on the main commit file (_lazyutils.py):
http://cvs.gnome.org/viewcvs/gnome-python/pygtk/gtk/_lazyutils.py?rev=1.1view=log
Anyway, it still take a lot of time and my guess is the size/number of
symbols of _gtk.so.
Yeah, wrappers add symbols, and symbols increase load time and code size.
I've made some not-often-used API optional in the gtkmm build to reduce
this slightly.
Yes, I know.
But I do think we can remove some symbols using the
g_object_{set,get}_property(). If some class provides a property that
maps to a function, like:
GtkLabel: gtk_label_set_text, gtk_label_get_text
we can avoid wrappers for these by using g_object_set and
g_object_get. At least in Python these will save enough, because it
would be done in Python itself, no ld is envolved, thus faster and
less stuff on _gtk.so
This is a fairly well known problem in the embedded world that is often
masked with splash screens. Many companies still seem to prefer the plus
of higher-level languages to the minus of longer load time. And maybe
someone will come up with a faster symbol resolver/ABI/file-format one
day.
I don't know. Maybe to solve the problem we have to break ABI... need
to check with libc guys why it's still slow.
--
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
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers
Re: python Re: [maemo-developers] Maemo 2.0 final release available
On 7/10/06, Murray Cumming [EMAIL PROTECTED] wrote:
Are you talking about something that happens for every class, or just
during library initialization? Either way, I'd love to see the patch, if
you have a URL.
PyGTK used to force calls to gtk_$CLASS_type() even for unused class,
during initialization.
About URL, they still use CVS, so there is not a snapshot about it
all... you may base your view on the main commit file (_lazyutils.py):
http://cvs.gnome.org/viewcvs/gnome-python/pygtk/gtk/_lazyutils.py?rev=1.1view=log
Thanks for the pointer.
[snip]
But I do think we can remove some symbols using the
g_object_{set,get}_property(). If some class provides a property that
maps to a function, like:
GtkLabel: gtk_label_set_text, gtk_label_get_text
we can avoid wrappers for these by using g_object_set and
g_object_get. At least in Python these will save enough, because it
would be done in Python itself, no ld is envolved, thus faster and
less stuff on _gtk.so
Yes, this is an advantage of Python's runtime-generated API that we don't
have in C++ and C. Of course, that causes runtime type problems instead of
compile-time problems, but if people are already using Python then they
are already content with that.
You will need to be careful - a small percentage of the get/set_*_()
methods in GTK+ probably do something more than just get/setting the
property.
[snip]
Murray Cumming
[EMAIL PROTECTED]
www.murrayc.com
www.openismus.com
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers
Re: python Re: [maemo-developers] Maemo 2.0 final release available
On 7/10/06, Tommi Komulainen [EMAIL PROTECTED] wrote: On Mon, 2006-07-10 at 09:29 -0300, ext Gustavo Sverzut Barbieri wrote: On 7/10/06, Frantisek Dufka [EMAIL PROTECTED] wrote: 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. Oh, it's only 4 seconds. I was under the impression it would be closer to 10. It's not *that* bad then :) 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. Ouch! Another contributing factor is probably the number of local symbols in _gtk.so that need to be relocated. sure. 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. We have maemo-launcher :) https://stage.maemo.org/svn/maemo/projects/haf/trunk/maemo-launcher/ I'll try Or, assuming that 95% of the time python on 770 would be used for GUI applications (rather than daemons, scripts or such) linking pygtk and pyhildon statically with python might be wortwhile optimization. Licenses permitting, of course. That's my idea and it's in my TODO :-) -- 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 maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: python Re: [maemo-developers] Maemo 2.0 final release available
On 7/10/06, Murray Cumming wrote:
On 7/10/06, Murray Cumming wrote:
Are you talking about something that happens for every class, or just
during library initialization? Either way, I'd love to see the patch, if
you have a URL.
PyGTK used to force calls to gtk_$CLASS_type() even for unused class,
during initialization.
About URL, they still use CVS, so there is not a snapshot about it
all... you may base your view on the main commit file (_lazyutils.py):
http://cvs.gnome.org/viewcvs/gnome-python/pygtk/gtk/_lazyutils.py?rev=1.1view=log
Thanks for the pointer.
[snip]
But I do think we can remove some symbols using the
g_object_{set,get}_property(). If some class provides a property that
maps to a function, like:
GtkLabel: gtk_label_set_text, gtk_label_get_text
we can avoid wrappers for these by using g_object_set and
g_object_get. At least in Python these will save enough, because it
would be done in Python itself, no ld is envolved, thus faster and
less stuff on _gtk.so
Yes, this is an advantage of Python's runtime-generated API that we don't
have in C++ and C. Of course, that causes runtime type problems instead of
compile-time problems, but if people are already using Python then they
are already content with that.
You will need to be careful - a small percentage of the get/set_*_()
methods in GTK+ probably do something more than just get/setting the
property.
Yes, it would need to be hand-pick.
Anyway, I still need to evaluate how much space and time we save, I'll
try to check it next week.
--
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
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers
