This is the mail archive of the
guile@sourceware.cygnus.com
mailing list for the Guile project.
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