[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Optimization of applicable smobs

From: Keisuke Nishida
Subject: Re: Optimization of applicable smobs
Date: 06 Dec 2000 22:26:31 -0500
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.0.92

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]