On 19.04.2007, at 22:02, Jerry D. Hedden wrote: Just a quick reply to one bit, rest snipped. I'll come back to the other suggestions later. > Anno Siegel replied: >> There is a speed hack that brings the performance of >> field hashes to better-than-refaddr, but not as fast as >> stringification (on my machine). I'm not using it because >> it changes the behavior in a subtle way. (Garbage >> collection could be bypassed if you use the refaddr of >> an object as a *string* hash key before first presenting >> the object as such. That won't happen in the intended >> usage, but it's a weak point.) > > That sounds interesting. Again, perhaps it could be added > as an optional feature. (Would you mind sending me the code > so I could marvel at it? Thanks.) The last version that implements it is one I abandoned for unmaintainability. You don't want that, trust me :) I'll try to re-introduce the speedup into the current version over the weekend. I'll send you that if it gets anywhere. The idea is to restrict all registry action to the first time a (ref-) key is stored in the field hash. That means another access to the field hash, but the existence test can use hv_fetch (instead of hv_fetch_ent). That bypasses uvar magic and makes it fast. Except for the first access (key creation), the effciency of the registry process doesn't matter any more. As noted, the problem is that someone could create the key for an object (by using its stringified refaddr) before the object proper is used as a key. The object would not be registered, and neither the garbage-collection liability. With the intended usage, hash keys will be refs, not strings, so this doesn't happen. But even %fieldhash_clone = %fieldhash_orig; would break. %fieldhash_clone wouldn't be garbage- collected. I'd also hate to describe that behavior to an unsuspecting user. I've come to take that as a design criterion. If a feature is a bitch to describe that may be because it's a misfeature. AnnoThread Previous | Thread Next