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