On Nov 10, 2008, at 4:28 PM, Stan Vassilev | FM wrote:
This wouldn't really help with the case here of "if ($array1 ==
$array2)..." though right? (not to say it's not good, just making
sure I understand ;-) ).
Yes I'm talking about speeding up scenarios full of hash lookups in
general.
Ok, still seems though like this particular optimization might also
provide additional benefits (albeit perhaps not nearly as significant).
It sounds like this would only work if the array contents where
static though, as you're mapping a constant string to the contents
of the hash (or did I misunderstand and you'd be mapping string
const. values to hash IDs?).
My point is, replacing this process:
$a['foo'] or $a->foo -> compute hash of 'foo' -> find item for hash
'foo' -> many items? -> resolve conflict -> return item
With this process:
$a[% string_literal_id_5 %] -> lookup item key 5 for array -> return
item
Notice we skipped hash generation, and conflict resolution
altogether. We only have the lookup for the integer id.
If some additional work is done, even this lookup can be eliminated
and make this an O(1) process.
If instead the coder used variable:
$a[$bar] or $a->$foo (var array lookup and var var object lookup),
then this optimization can't kick in, and the existing algorithm
will be used.
However "static" access is the predominant usage, especially for
objects, but also for arrays, so this should have significant impact.
Thanks for the clarification, this is pretty much the same idea as
what I've been interested in working on next. I think I was more
inclined to store an extra hash value within the zvals themselves,
with the hope that this could be expanded to non-constant values. I
believe ruby implements it's lookups this way (noted just for
reference, not as an argument to copy another language ;-) ). Any
thoughts on reasons not to do this (other than increasing the size of
zval struct), it's pretty simple to implement this for static values I
believe, dynamic values are a lot more difficult obviously...
-shire
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
