Re: Re: zend_fast_hash

From: Date: Thu, 22 May 2003 14:23:02 +0000
Subject: Re: Re: zend_fast_hash
References: 1 2 3 4  Groups: php.internals 
Request: Send a blank email to internals+get-1889@lists.php.net to get a copy of this message
At 15:03 22.05.2003, Sterling Hughes wrote:
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.
I know the reasons for adding it quite well - I'm just less confident that they'll end up bringing substantial gains. Have you benchmarked the two beasts against each other? Do you have some figures as to difference in memory requirements? My point is that while it feels bad to use such a feature-bloated hash for all the stuff that we use it for, I think the gain from switching to something different will be negligible, and won't justify duplicating the code. I could be wrong, it's my educated guess, and others' educated guesses are different. We simply need to check.
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?
Like function_table - you only have a single instance per request, or if you use OO, another one per class (still a relative small number of instances, vs. objects/arrays).
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.
Maybe. I don't mind if you commit and try to move stuff over, as long as if it ends up not bringing a substantial gain (i.e., less than 5% or so) we (read: you :) would roll back. There's an inherent drawback in duplicating code from a maintenance point of view, so we have to justify that price... Zeev

« previous php.internals (#1889) next »