First look at new g-wrap -- it's slow!

[Andy Wingo]

Yo,

I took a first look at the new g-wrap. Yes I know I've been a bit
derelict. Oh well. Here are my thoughts and concerns.

The new code makes (gnome gtk) load slower for me (~13s vs ~10s), and
also defines about 1000 more symbols, about 65 more with the <gtk-
prefix. The numerical difference is probably due to gtk 2.4 vs 2.2.
Damn. I was expecting it to load up in less time. I tried to
profile it but I don't have a working copy of guile's sources to compile
with profiling. I then compiled it (and the new g-wrap) with -O3, which
died after about 13 minutes of compilation with gcc-3.3. Instead of
dying nicely, gcc-3.2 was oom-killed. Tried again with -O2. Same. Tried
with -O. It worked, but with no performance improvement.

Moral of the story: -O doesn't help. Profiling would help, but you need
an instrumented guile to do that. What's wrong? What does your
performance difference look like? Is it just that the bottleneck is the
same (add-method!)?

Now, to the nits:

In the docs you give the example, (generate-wrapset guile 'my-wrapset
"my-wrapset"). Why is there a need for a secondary namespace of
wrapsets? Wouldn't (generate-wrapset <my-wrapset> "my-wrapset") suffice?
Same with depends-on!.

Also, I think depends-on! is a bad name, because it doesn't include a
verb. If you do an apropos on "!", you'll find all of those procedures
include a verb. Perhaps add-dependency! or something would be good. I
even like ws-add-dependency! better. More about generics in an email to
guile-user.

Another thing I don't understand is, when defining new types, why do you
have to derive a class, then instantiate the derived class? Is this to
get around GOOPS' lack of class methods?

I think the type parameter of the unwrap-value-cg and wrap-value-cg
methods should be a <timespec64-type>. Also the second unwrap-value-cg
should be wrap-value-cg. I think you were sleepy when you wrote those ;)

Regarding the C output: it's difficult to read. Perhaps it should be run
through indent if indent is available. Dunno.

Another C issue: Why do functions need any prefix other than _wrapper? I
see the need from a generality perspective, but even the current method
isn't foolproof -- the only way to be completely general is to allow the
user to specify the name of the c wrapper herself. Python does it this
way.

Your scheme modules in general need a couple-sentence commentary at the
top. For example, it took me a while of poking around to figure out what
rti means. A short sentence or two would orient the reader as to what
the file is trying to do.

Is it possibile to include this code in our tarball via arch
multi-projects? It's appealing in light of the 2.8 bindings process, and
the slowness of g-wrap releases.

In the docs: the C values that need _destruction_, not deconstruction, I
think. Also, shouldn't it be destroy-value-cg instead of
destruct-value-cg?

One of the g-wrap tests fails: "output arguments work as advertised"

OK. It looks good, but the lack of class methods, the dual namespaces,
and performance problems really are problems. What can we do to fix
those? And in the meantime, can we / should we use it in guile-gnome?

Regards,
-- 
Andy Wingo <address@hidden>