Re: Re: zend_fast_hash

> > 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 :) > I think you misunderestimate HANDLE_NUMERIC(), and some of the other little overheads introduced. I think the major different between the current hashtable implementation and the new one, is that the new one has no intention of being used to facilitate PHP arrays. > >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. > Singular hashes? There will be a nice gain in memory, and again, I think there will also be a CPU gain, not really signifigant mind you, but zend_hash's are used so often, that I think you'll be surprised at the outcome. > 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. > Ok. I'll take a look at converting some places over. > 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. I'll save you the suspense. Andi is right ;-) -Sterling -- "That stuff's easy compared to installing Horde" - Alan Knowles, In response to my applause for creating a LALR parser for PHP.