[OPEN-ILS-DEV] osrfHash: alternative implementation

[Bill Erickson]

Scott McKellar wrote:
> The attachments are an alternative implementation of the osrfHash
> code.  I believe that this implementation is simpler and more 
> efficient than the existing one, while providing the same functionality
> (barring any bugs that I haven't found yet).
>
> These are NOT ready to be installed as replacements for the current
> code.  First of all, much of it is untested at this point.  Second,
> the rest of the code base isn't ready for it.  We would need to change
> any code that directly accesses the internal members of an osrfHash
> or osrfHashIterator.  In particular, some files reference the "current"
> member of an osrfHash Iterator.
>   

I like the approach and I'm still digesting this to some degree.

(from your previous email)

"The osrfStringArray supports traversal of the keys in the same sequence in which they were added.  This ability is particularly important in the context of a jsonObject, where the sequence of entries in a series of name/value pairs may be significant."

This isn't exactly the purpose.  The osrfStringArray was kept around mostly for speed.  When I was testing the hashes, there were lots of cases of "give me the list of keys for this hash".  Generally, it was (or seemed, with my contrived tests) faster to just keep the keys around than to create them on the fly.  However, the linked list implementation (as opposed to scanning through sparse arrays) will speed up the key generation a good bit, I would imagine.  

(also)

"I suspect that the idea behind this is that we want the iterator to do 
something sensible even if the item has been deleted (though it's not 
clear to me whether this situation occurs in practice)."

And it shouldn't.  The intention was never to support mid-iteration item 
deletions.  I think this is more of a unintentional (and hopefully 
unused) side effect.


My feeling is that the ability to change a hash during iteration is a 
bad thing and retaining sort order on the hash keys is not necessary.  
If that simplifies your test implementation, great.  Regardless, I agree 
we should start moving in this direction.  I can start by adding an 
osrfHashIteratorKey() function to the current implementation so other 
code can start using it.

Thanks, Scott.  The osrfHash is one of the most highly used components 
in OpenSRF and any performance boost will be felt throughout.


-bill

-- 
Bill Erickson
| VP, Software Development & Integration
| Equinox Software, Inc. / The Evergreen Experts
| phone: 877-OPEN-ILS (673-6457)
| email: erickson at esilibrary.com
| web: http://esilibrary.com