[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