This is the mail archive of the
guile@sourceware.cygnus.com
mailing list for the Guile project.
Re: interface reductions
- To: Mikael Djurfeldt <mdj at mdj dot nada dot kth dot se>
- Subject: Re: interface reductions
- From: Dirk Herrmann <dirk at ida dot ing dot tu-bs dot de>
- Date: Thu, 25 May 2000 12:11:18 +0200 (MEST)
- cc: Guile Mailing List <guile at sourceware dot cygnus dot com>, djurfeldt at nada dot kth dot se
On 25 May 2000, Mikael Djurfeldt wrote:
> Mikael Djurfeldt <mdj@mdj.nada.kth.se> writes:
>
> > > SCM_FAST_FLUID_REF --> scm_fluid_ref
> > > SCM_FAST_FLUID_SET_X --> scm_fluid_set_x
>
> These were provided from the start. As explained in the commentary in
> fluids.h, the purpose is to provide a fast fluid access method. This
> is also reflected in the names.
>
> Q: Why would you need fast access to fluids?
>
> A: The aim is of course that *all* thread-local SCM-type state
> information in Guile should be represented by fluids. Currently
> time-critical such information is stored in the root state, but
> we plan to remove the root state. Then SCM_FAST_FLUID_REF will
> probably be needed.
>
> My guess is that the original motivation for providing them was to
> encourage people to use fluids instead of adding things to the root
> state.
>
> I don't think these macros restricts the implementation of fluids. I
> think they are pretty OK.
But, then we should at least also provide SCM_FLUID_REF. Currently to
have fast access to a fluid, you have to do:
SCM_FAST_FLUID_REF (SCM_FLUID_NUM (x))
i. e. you can't even avoid to work with the implementation detail that
fluids are stored in a vector. Thus, to at least remove this problem a
bit, I suggest:
#define SCM_FLUID_REF(x) (SCM_FAST_FLUID_REF (SCM_FLUID_NUM (x)))
#define SCM_FLUID_SET_X(x, v) (SCM_FAST_FLUID_SET_X (SCM_FLUID_NUM (x), (v)))
Then, the difference between SCM_FLUID_REF and SCM_FAST_FLUID_REF is, that
the first requires one additional memory access, namely to the CDR of the
fluid. However, it's still faster than calling the scm_fluid_* functions.
(I think it's still questionable to keep the _FAST_ variants, since it's
somewhat unlikely that people will store the fluid number for longer
times. And, if they do, it's even probable that later accesses to that
number will also cause a memory access. In contrast, in a more local
context the compiler should be able to eliminate redundant accesses to the
CDR of the fluid.)
Best regards
Dirk