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

[From: Gustavo Sverzut Barbieri]

On 7/10/06, Murray Cumming <murrayc at murrayc.com> wrote:
> > On 7/10/06, Frantisek Dufka <dufkaf at seznam.cz> 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.1&view=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: 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