Speedups for GTK2 bindings?

Speedups for GTK2 bindings?

[Andreas Rottmann]

Hi!

I'll probably try what speedups result of re-implementing the
re-export-bindings and functions->methods-public helpers in C. 

FYI: A "guile -c '(use-modules (gnome gtk))'" takes ~10 seconds ATM
using Guile 1.6.4 on a 900Mhz Athlon. Most time is spent in building
the generics an re-exporting the bindings (which I hope to reduce by
re-implementing the above functions in C).

If anyone else has any idea how to make the bindings load faster,
please step forward and tell me, I'll maybe even implement them ;-)

Regards, Andy
-- 
Andreas Rottmann         | Rotty@ICQ      | 118634484@ICQ | a.rottmann@gmx.at
http://www.8ung.at/rotty | GnuPG Key: http://www.8ung.at/rotty/gpg.asc
Fingerprint              | DFB4 4EB4 78A4 5EEE 6219  F228 F92F CFC5 01FD 5B62

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

Re: Speedups for GTK2 bindings?

[Andy Wingo]

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. 

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.

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.

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,

wingo.

Re: Speedups for GTK2 bindings?

[Andreas Rottmann]

Andy Wingo <wingo@pobox.com> 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 ;)
>
OK.

Regards, Andy
-- 
Andreas Rottmann         | Rotty@ICQ      | 118634484@ICQ | a.rottmann@gmx.at
http://www.8ung.at/rotty | GnuPG Key: http://www.8ung.at/rotty/gpg.asc
Fingerprint              | DFB4 4EB4 78A4 5EEE 6219  F228 F92F CFC5 01FD 5B62

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

Re: Speedups for GTK2 bindings?

[Andreas Rottmann]

Andy Wingo <wingo@pobox.com> 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.
>
It seems that the speed gains from doing the generics stuff from C
(I've made up a version that is basically the scheme code translated
to the Guile C API) are minimal at best. I think that the add-method
invocation is the slow call. I've yet to profile the code to see what
causes it to run so slow.

Regards
-- 
Andreas Rottmann         | Rotty@ICQ      | 118634484@ICQ | a.rottmann@gmx.at
http://www.8ung.at/rotty | GnuPG Key: http://www.8ung.at/rotty/gpg.asc
Fingerprint              | DFB4 4EB4 78A4 5EEE 6219  F228 F92F CFC5 01FD 5B62

Python is executable pseudocode, Perl is executable line-noise.

Re: Speedups for GTK2 bindings?

[Andreas Rottmann]

Andreas Rottmann <a.rottmann@gmx.at> writes:

> Andy Wingo <wingo@pobox.com> 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.
>>
> It seems that the speed gains from doing the generics stuff from C
> (I've made up a version that is basically the scheme code translated
> to the Guile C API) are minimal at best. I think that the add-method
> invocation is the slow call. I've yet to profile the code to see what
> causes it to run so slow.
>
I've now checked in most of my non-GError related changes to
guile-gobject. This includes creating the generic functions immediatly
(as suggested by Andy Wingo), not in a seperate pass, which is cleaner
IMO and also reduces the binding load time by about 10% on my machine
(10 seconds -> 9 seconds -- YMMV, I'd like to get this number
verified...)

Regards, Andy
-- 
Andreas Rottmann         | Rotty@ICQ      | 118634484@ICQ | a.rottmann@gmx.at
http://www.8ung.at/rotty | GnuPG Key: http://www.8ung.at/rotty/gpg.asc
Fingerprint              | DFB4 4EB4 78A4 5EEE 6219  F228 F92F CFC5 01FD 5B62

Python is executable pseudocode, Perl is executable line-noise.

Re: Speedups for GTK2 bindings?

[Kevin Ryde]

Andreas Rottmann <a.rottmann@gmx.at> writes:
>
> If anyone else has any idea how to make the bindings load faster,
> please step forward and tell me, I'll maybe even implement them ;-)

I wonder if adding a large number of symbols means longish alists in
the symbol obarray in 1.6.4.  Probably can't do anything about that,
but in the guile cvs maybe repeated rehashes could be avoided by some
sort of hint or resize for about what's about to be added.

I guess there's strndups of the symbol names too.  Might be nice if
there was a way to do a take_str type thing when it's a constant
passed to scm_c_define_gsubr or whatever.