guile-gtk-general
[Top][All Lists]
Advanced

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

Re: [g-wrap] Changes needed by the "glueless" approach


From: Andreas Rottmann
Subject: Re: [g-wrap] Changes needed by the "glueless" approach
Date: 03 Nov 2003 12:10:30 +0100
User-agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Common Lisp)

Andy Wingo <address@hidden> writes:

> On Sat, 25 Oct 2003, Andreas Rottmann wrote:
> 
> > Andy Wingo <address@hidden> writes:
> > 
> > > BTW. gcc (GCC) 3.3.2 20030908 (Debian prerelease) compiles things fast
> > > for me now, no more 10 minutes waiting for an OOM kill. What are you
> > > doing this for, anyway?
> > >
> > Well, my experience is with gcc 3.3.2 (Debian):
> > 
> > cc1: out of memory allocating 182094100 bytes after a total of 19058688 
> > bytes
> 
> Man, mine started doing that the other day too. 2.4. I think I was just
> having strange things happen with ccache (I normally use CC='ccache
> gcc').
> 
> > Of course this was done with -O2 on the ~140K line binding, -O0 works
> > fine.
> 
> Hm, interesting. You say in another mail that you have (gnome gtk)
> loading reasonably quickly. How long before we can see that in CVS? I'm
> really looking forward to it, hope we don't get bogged down waiting for
> g-wrap to move.
> 
The problem is that I don't have clean changesets (since I started
hacking befor using TLA/Arch) of the performance improvements and the
changes that depend on the new g-wrap (since the new g-wrap does
method creation).

However, I think the performance increase I managed to get was mainly
replacing the calls to scm_make() with the something like

 generic = scm_call_3 (scm_sym_make, scm_class_generic,
                       k_name, generic_name);

where scm_sym_make is

scm_sym_make = scm_permanent_object (
            SCM_VARIABLE_REF (scm_c_module_lookup (scm_module_goops,
                                                   "make")));

Also, I think that Guile 1.7 is faster than 1.6 wrt generic creation
(try removing the name keyword and argument, this should increase
speed on 1.6; speeds are related approx. like this, AFAIR: 1.6 (with
k_name) slower than 1.7 (with k_name) slower than 1.6 (without k_name)
slower than 1.7 (without k_name); where 1.7 with k_name and 1.6
without k_name are not that much different, and all of the above
combinations are way faster than using scm_make().

Regards, Andy




reply via email to

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