Re: zend_fast_hash

On Wed, 2003-05-21 at 11:49, Zeev Suraski wrote: > Can you explain how it is simpler? :) Writing a lightweight hash has been > on our mind for quite some time, but the reason it never happened is that > it appears that most of the places that use hashes actually do take > advantage of the non-bare-bones features. The biggest difference I can > spot is that there's no linked list that links all of the elements. But if > we end up adding apply, and clean (which are actually used a lot outside > the scope of symbol tables), and soon enough we'd also need merge, copy and > unnamed elements - I'm not sure it's worth the trouble of having two Except for unnamed elements, those are all trivial to implement with the code I've attached. In fact, apply, copy and clean are in there, merge could be done when I figure out the semantics. :) Unnamed elements are impossible, but they should be. If you need unnamed elements, either the code is taking advantage of a feature that shouldn't be there, or one should just use the old hashtable implementation, which will still be available. I dare say that in most cases, using unnamed elements is not necessary. The major API hurdle here is reliance on insertion order, which is used once or twice in the code (not that often, afaik), but I believe that can be changed, and made to work with the new API. I believe I can change over all the symbol tables (EG(function_table), etc.) to use my new hash implementation, and it will be signifigantly faster. I'm holding off on that for now, cause I don't want to muddy the commit/patch. This hashtable implementation requires signifigantly less memory, and has a lower overhead then the standard HashTable. Considering how often hash functions are used in Zend, I think it going to be a big win. -Sterling -- "First they ignore you, then they laugh at you, then they fight you, then you win." - Gandhi