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] |
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