Re: Re: zend_fast_hash

At 17:37 21/05/2003, Sterling Hughes wrote:

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. :)

I know, and I knew that already :) That's kinda what I fear.

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.

Again, the problem in my opinion is that you will soon find out that without adding all the bells and whistles of the Zend hash table, you won't be able to use it for almost anything. And once you add all the bells and whistles of the Zend hash table, it won't be significantly more light-weight, and won't justify the duplicated code. The 'start simple and add stuff as necessary' held true for the Zend hash too. It started in 1997 as a very simple thing, and what you see now is what we needed to add ever since :)

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.

Looking at it, it appears the the major difference is the removal of the global linked list. I don't think there's going to be a substantial gain in performance, there will be some gain in memory, but if we only use it for 'singular' hashes like function_table, that's going to have negligible effect. One advantage we have today (vs. 1997) is that we know fairly well what we need. I think that before we introduce a second hash to the engine, we should have a pretty good idea about where it could be used, and what kind of effect (gain) it's going to have. If you could come up with a list of places where this hash can be used, plus some numbers as to what kind of gains (in terms of memory and performance) we can expect, I think we'd be in a better position to decide whether this should go in or not. Zeev P.S.: As might be evident from Andi's response, we've actually been discussing this issue for several years now. My position was that we'd find very little usage for this hash, because we've grown to rely on many of the extra features of the Zend hash just about everywhere. Andi's position was, more or less, "there must be something we can do" :) I guess it's showdown time.