Re: Optimization of applicable smobs

[Mikael Djurfeldt]

Keisuke Nishida <address@hidden> writes:

> There is an alternative method.  Instead of creating new fields in each
> smob descriptor, we can store functions corresponding to each gsubr_type
> in a global table.  This is more space efficient if there are more than
> 32 smob types.

On the other hand, compared to the rest of the memory which Guile
uses, this memory consumption is negligible.  For 100 smob types,
these fields take 100 x 5 x 4 bytes = 2K.  Compare that to the usual
heap size of around 500K...

It also would mean an extra indirection, or?  If that is the case, we
should trade memory for speed.

> Regarding tail-recursiveness, what about adding a new flag that
> indicates that the return value of a smob application must be called
> once again tail-recursively?

Yeah, we need something like this.  Note that we need to return the
arguments as well...  Also, we should coordinate this change with
Gary's recent implementation of multiple values.

Mikael