This is the mail archive of the guile@sourceware.cygnus.com mailing list for the Guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Making Guile slower


Mikael Djurfeldt <mdj@mdj.nada.kth.se> writes:

> Greg Harvey <Greg.Harvey@thezone.net> writes:
> 
> > Consider this:
> > 
> > SCM_NEWCELL(foo);
> > SCM_SETCDR(foo, scm_must_malloc(foo_size, s_make_foo));
> > SCM_SETCAR(foo, scm_tc16_foo);
> 
> ... which should be written ...

Yes, but it rarely is ;) (I started to change it over, but there were
so many places that I felt a better solution was needed).

>   m = scm_must_malloc (foo_size, s_make_foo);
>   SCM_NEWCELL (foo);
>   SCM_SETCDR (foo, m);
>   SCM_SETCAR (foo, scm_tc16_foo);
> 
> Wouldn't it be a solution, then, to abstract away this idiom, e.g. as
> a macro, so that we both gain readability, safer code, and get the
> freedom still to choose an efficient from of the NEWCELL operation
> itself?

The overall problem is that, even if we handle common cases, it's
still too fragile: it's just too easy to screw up the order of
allocations in code more complicated than this; even this change
doesn't handle cases where you're playing around with just cells.

Which is not to say that this shouldn't be automated when possible. If
it's hidden in a macro, it could be possible to forgo the
initialization, but in this case, we should be even more `inefficient'
and initialize m to values safe for the gc to look at (though this is
harder to do correctly, since smobs may be using m in weird ways that
we could screw up if a mark starts before the object is fully
initialized).

-- 
Gregh

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]