On Sat, 2007-10-06 at 16:04 -0700, Bill Dortch wrote: > - Implementing the tables directly rather than as a component > provided a significant performance benefit -- somewhat to my surprise. > I did originally take the latter approach. The code is in > bdortch/attrs/src/org/jruby/runtime/component, in VariableStore > (abstract base class) and ConcurrentObjectVariableStore, which may yet > find some use (in a somewhat modified form) once we refactor > IRubyObject/RubyObject.
Hmm. What about performance as a standalone class? The addition of an abstract base class can potentially have a performance impact by itself, since it complicates method dispatching. > However, I don't think it's unreasonable to implement these directly > for performance (see RubyArray and RubyHash, for instance). I guess so ... I'm just a little worried about the code getting copy-and-pasted different places (e.g. for constant tables or something) this early in its life-cycle. Once that happens it's unlikely that any future fixes will get uniformly applied. (The rest of your code does look correct to me, though.) > re: IDs, in the abstract I like the idea, need to see what that means > in concrete terms, what the overhead would be, etc. In the meantime, > I think the rule can be, when in doubt, don't call the "fast" > accessors. Maybe I should rename them: scaryFastGetInstanceVariable? How about unsafeGetInstanceVariable or uncheckedGetInstanceVariable? -mental
signature.asc
Description: This is a digitally signed message part
