This is the mail archive of the guile@cygnus.com mailing list for the guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: setf.scm



mdj@nada.kth.se writes:
> Maciej Stachowiak <mstachow@MIT.EDU> writes:
> 
> > It definitely should be efficient. I think the right thing to do is to
> > add an extra setter slot to procedure objects
> 
> I'm not happy about this.  Note that this would make closures
> heavier.  It should be cheap to create closures in the interpreter.
> 
> Is the setf! functionality really useful enough to motivate making
> closures heavier?
> 

I've been trying to figure out how closures are laid out so I can make
a guess as to whether this will be true. Right now it seems closures
are a cons cell, the car of which is a cons cell of the code and the
properties, and the cdr of which is the environment. I can see what
you mean about the extra indirect references, but I'd need to see
benchmarks to be convinced how much of a difference this makes. I am
also curious if the decision to make the code more indirect rather the
environment was random or based on performance analysis of the two
possibilities.


> (I've actually been thinking about removing the procedure-property
>  slot.  That would remove one level of indirection in the inner loop
>  of the evaluator.)

Actually those could easily live in a separate weak hash table as
accessing them hardly ever performance critical. Are there any
procedure properties that need to have special semantics other than
arity? 

 - Maciej