Re: Making Guile slower

[Greg Harvey <Greg dot Harvey at thezone dot net>]

Marius Vollmer <mvo@zagadka.ping.de> writes:

> Is anyone worried about this change re performance?
> 
> 1999-12-10  Greg Harvey  <Greg.Harvey@thezone.net> (applied --12/10/99 gjb)
> 
> 	* smob.c (scm_smob_prehistory): initialize allocated smob
> 
> 	* tags.h: new tag: scm_tc16_allocated
> 
> 	* gc.c (scm_gc_for_newcell): set the car of the new cell
> 	to scm_tc16_allocated
> 	* pairs.h (SCM_NEWCELL): set the car to scm_tc16_allocated
> 	(scm_gc_mark): mark allocated cells.
> 
> I am somewhat, because SCM_NEWCELL now seems to perform one more
> operation.

Did you even think about what this is accomplishing before you started
worrying about the performance or are you now just on a hunt to show
that we're trying to make guile perform poorly?

Consider this:

SCM_NEWCELL(foo);
SCM_SETCDR(foo, scm_must_malloc(foo_size, s_make_foo));
SCM_SETCAR(foo, scm_tc16_foo);

This is very common in guile (though this is not the case that can go
wrong; any kind of allocation after the newcell is sufficient). Now,
look at gc.c; see what the gc does when it finds a freecell (and this
is what the gc should do). See if you can guess what happens to the
object if that scm_must_malloc triggers a gc. If you were to say "hey,
that cell can be put on the freelist, even though I'm just about to
use it! I'll be screwed when a call to NEWCELL gets back that cell"
you'd be right, and that's exactly why it was changed. If you feel up
to going through all the guile code and all the c code that uses guile
and changing it so that the order of allocation is safe, then feel
free to revert the patch.

-- 
Gregh