Re: Re: zend_fast_hash

> >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. > > Let's keep it as simple as possible because if we start adding features it > will be zend_hash.*. Only places which need a simple hash should use it and > places which need something more powerful should continue to use zend_hash.* > That's my idea at least. Start simple, improve or add features as deemed 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. > > I don't think EG(function_table) can use it because I think it uses a > reverse_apply(). > Right. That's a terrible usage for it though (not saying I have a better idea :) It could still be done somewhat efficiently (i prepend elements onto the chains, so you could read each bucket until an internal function is reached.) I don't know though, that would need some benchmarking, I'm not sure which would be more efficient. Still, we can cross that bridge when it comes. -Sterling -- "A business that makes nothing but money is a poor kind of business." - Henry Ford