Re: Optimization of applicable smobs

[Keisuke Nishida]

Mikael Djurfeldt <address@hidden> writes:

>    Here's a suggestion for a more efficient approach:
>
>    * We replace the current gsubr_type field in the smob descriptor
>      with the fields trampoline0, trampoline1, trampoline2, and,
>      trampoline3.
>
>    * Instead of having the trampolines in switch statements, we
>      implement them as separate C functions.
>
>    * Instead of calling the *generic* function (not in the OO sense!)
>      scm_apply_smob_0 in the evaluator, we call the function stored in
>      trampoline0.  This field is *ahead of time* prepared with a
>      trampoline function which translates a zero arg call to the shape
>      appropriate for the function stored in the `apply' field.
>
>    * scm_set_smob_apply in a sense "compiles" the type by selecting
>      the appropriate trampolines at type creation time.
>
>    * Note now the possibility for a nice optimization:
>
>      If the function stored in `apply' takes, for example, two
>      required arguments, then the *function itself* can be stored in
>      `trampoline2', and we have eliminated one level of indirection.

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.

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?  This is not very clean but should work...

-- Kei