This is the mail archive of the mailing list for the Guile project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Speedups for GTK2 bindings?

Andy Wingo <> writes:

> On Tue, 19 Aug 2003, Andreas Rottmann wrote:
>> I'll probably try what speedups result of re-implementing the
>> re-export-bindings and functions->methods-public helpers in C. 
> Great! A lot of that code is (as you know) slow slow slow slow slow, and
> since I don't fire up the gtk side of things too often, I don't really
> see it very much.
> From informal observation, the slowest parts of the whole thing are
>  * loading (gnome gtk gw-gtk), which means registering all of the
>    functions (takes about 10s or so on my machine)
>  * loading (gnome gtk generics) (takes about 15s or so)
> I think that re-export-bindings procedure is kindof hackish; I think I
> saw another module saying something like
> (set-module-uses! (gnome gtk %module-public-interface) (gnome gtk gw-gtk
>   %module-public-interface))
> or something like that (not in (gnome gtk), but something within guile
> itself). This sort of thing sounds like a question to ask guile-devel...
> Also, I don't think re-export-modules takes all that much time either.
> Dunno though, it would be helpful to time things so you can quanitify
> improvement. 
Right, on my machine also the registering and generics-building takes
the vast amount of time. I'll leave re-export-bindings alone.

> With regards to the slowness in loading gw-gtk, that's g-wrap's
> slowness. You might try profiling the code to see if some code path is
> really inefficient (like calling scm_c_lookup() too many times or
> something). I haven't done this yet because it hasn't pissed me off
> enough, but using gtk daily would do it ;) Anyway, this could be fixed
> in g-wrap -- there's no reason for it to take so long, PyGTK loads up
> quickly.
I'll have a look at the code-generation anyway - we generate much more
code than pygtk does :-/

> Now, making the generics. Perhaps that could be done at the same time as
> the functions are registered; that would avoid all the setting of
> procedure properties that is done in the ccodegens.
That's probably a good idea.

> These are just some ideas I'd had, dunno how correct they are. Heed them
> or not, as you like! BTW, you can go ahead and commit your fix. Also,
> Andreas you can commit anything else that seems correct to you,
> especially if it results in faster load times ;)

Regards, Andy
Andreas Rottmann         | Rotty@ICQ      | 118634484@ICQ | | GnuPG Key:
Fingerprint              | DFB4 4EB4 78A4 5EEE 6219  F228 F92F CFC5 01FD 5B62

Latein ist das humanoide Äquivalent zu Fortran.
   -- Alexander Bartolich in at.linux

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]