public inbox for guile-gtk@sourceware.org
 help / color / mirror / Atom feed
From: Andy Wingo <wingo@pobox.com>
To: guile-gtk@sources.redhat.com
Subject: Re: Speedups for GTK2 bindings?
Date: Wed, 20 Aug 2003 14:11:00 -0000	[thread overview]
Message-ID: <20030820135934.GB4770@lark> (raw)
In-Reply-To: <87r83hea6e.fsf@alice.rotty.yi.org>

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.

  reply	other threads:[~2003-08-20 14:11 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 [this message]
2003-08-20 15:03   ` Andreas Rottmann
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=20030820135934.GB4770@lark \
    --to=wingo@pobox.com \
    --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).