> 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
