Re: cons expensive? (was Re: DHARMI project)

[Telford Tendys <telford@triangle.triode.net.au>]

> cons had better not be expensive!  Lists have to be fast in guile, and
> lists are built from consing things.  Of course, there are bigger
> things you can build in one go (like vectors), but why is cons so
> expensive for your application?

Well I looked at trying to speed up the garbage collector but
(to the extent of my understanding) there's nothing much to be improved --
it has no choice but to classify each and evey item of live data,
then mark those that need marking and scan the links of those that
contain links. What's there seems pretty much the bare minimum of
what can be there. Maybe there's tricks that I have no idea about...

As for speeding up cons itself, it already uses a freelist system
for recycling cells which should be quite quick, still it turns up
quite high in the gprof list, probably because it gets called an
incredibly large number of times.

Since I use a lot of floating point numbers, there is an implicit
cons for every calculation of every number (they are stored indirectly,
actually scm_cons() is not used but SCM_NEWCELL() is and the result
is much the same). Beating this would involve completely reworking the
framework of types that guile uses, a massive task and potentially
leading to more problems than it fixes <sigh>.

One thing that I do notice (from pairs.h):

#define SCM_NEWCELL(_into) \
	{ \
	  if (SCM_IMP(scm_freelist)) \
	     _into = scm_gc_for_newcell();\
	  else \
	    { \
	       _into = scm_freelist; \
	       scm_freelist = SCM_CDR(scm_freelist);\
	       ++scm_cells_allocated; \
	    } \
	}

What does scm_cells_allocated do? Can it be removed from this
macro? I know it seems insignificant in terms of overhead but
this macro is called LOTS of times.

	- Tel