On Nov 5, 2008, at 7:22 AM, Graham Kelly wrote:
Hi,
I played with a patched version of compare_function with this
optimization in it. Other then for strings it didn't seem to make
much of a difference. A quick test showed that in an average php
application only about 0.15% of calls to compare_function actually
have the same op1 and op2. Considering it doesn't make much of a
difference for anything except string comparison (and maybe arrays?)
it probably isnt worth putting it in compare_function. This
certinally is not a common case and would only serve to add an extra
needless comparison and branch to the other 99% of calls to
compare_function. Also, it seems as if in most cases this type of
behavior could be detected and handled appropriatly at compile time
by a good optimizer.
I started looking at this briefly, and agree with what you describe
above. I was curious to see if anyone came back with any real world
applications where they where hitting this scenario but it seems
unlikely.
However, while the common compare_function call probably wouldent
gain anything from this, maybe it could be put in the
TYPE_PAIR(IS_STRING, IS_STRING) case or put into zendi_smart_strcmp
(which only seems to ever be called by the TYPE_PAIR(IS_STRING,
IS_STRING) case of compare_function).
I havent played with the patched version of zend_hash_compare to see
if it might provide any real world savings. Though it appears as if
that function might see a significant improvement for these cases.
Arrays and strings do seem to be the only real worth while comparisons
for this type of optimization, but only because the costs of comparing
long strings and large array lists make the savings more significant.
I think it might be hard to see this in a real world application
though, so it would be nice if someone could justify the change by
showing test results. I'll try to bench Facebook's code base to see
what we can get out of it.
-shire
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php