guile-user
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: New g-wrap supported in guile-gtk--rotty-0.1!


From: Mikael Djurfeldt
Subject: Re: New g-wrap supported in guile-gtk--rotty-0.1!
Date: Thu, 04 Dec 2003 09:14:18 -0500
User-agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3 (gnu/linux)

Andreas Rottmann <address@hidden> writes:

> [ CC'd guile-user, since maybe someone has an idea how to implement
>   this ]
>
> Kevin Ryde <address@hidden> writes:
>
>> Andreas Rottmann <address@hidden> writes:
>>>
>>> I now get ~3.6 seconds of loading time for (gnome gtk) with the above
>>> referenced code, gcc 3.3.2 -O2 and Guile 1.7 on my Athlon 900. The
>>> loading time is mostly spent in scm_add_method(), FWIW...
>>
>> I wonder if some lazy initializing would be possible, like catch a
>> failed method dispatch and add only at that time.  (But my ignorance
>> of goops is pretty profound, so maybe it's not feasible.)
>>
> I don't really know. Maybe one could postpone the method creation
> until the first instance of that class has been instantiated...
>
>> gtk+gnome is pretty big, there might be a good chance an application
>> would use only a modest number of widgets and functions.  Those needed
>> to get the first window up could be even fewer.  (Always good to get
>> the first window up quickly, since the user is waiting, waiting ...)
>>
> Yes, I also think that we *have* to get the "time-to-initial-window"
> at least under 1 second for a hello world program...

GOOPS is, as yet, only optimized for fast execution.  Creation of
objects and *especially* method creation involves a lot of work, most
of which is done by interpreted Scheme code.

This is not an architectural problem, though, and it is certainly
possible to speed things up.

An improvement of method addition on the algorithm level that could
help this particular case would be to allow for adding multiple
methods at once.  Presently, every call to scm_add_method involves
re-computing the methods list of the GF which means that adding N
methods to a GF is O(N^2).

An improvement on the implementation level would be to do part (or
all) of the work in C.  This, however, should be done with preserved
respect for the MOP.  Anyone who wants to do this should talk to me
first.

(Unfortunately, I can't do any work on GOOPS right now.  Hopefully
I'll be able to go over a few issues with GOOPS starting next summer.)

M




reply via email to

[Prev in Thread] Current Thread [Next in Thread]