From: Andreas Rottmann <a.rottmann@gmx.at>
To: guile-gtk@sources.redhat.com
Subject: Re: Speedups for GTK2 bindings?
Date: Wed, 20 Aug 2003 15:03:00 -0000 [thread overview]
Message-ID: <87n0e4nzes.fsf@alice.rotty.yi.org> (raw)
In-Reply-To: <20030820135934.GB4770@lark> (Andy Wingo's message of "Wed, 20 Aug 2003 14:59:34 +0100")
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
next prev parent reply other threads:[~2003-08-20 15:03 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-08-19 19:09 Andreas Rottmann
2003-08-20 14:11 ` Andy Wingo
2003-08-20 15:03 ` Andreas Rottmann [this message]
2003-08-20 17:52 ` Andreas Rottmann
2003-08-27 4:26 ` Andreas Rottmann
2003-08-21 22:51 ` Kevin Ryde
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87n0e4nzes.fsf@alice.rotty.yi.org \
--to=a.rottmann@gmx.at \
--cc=guile-gtk@sources.redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).