Okay, I was wondering about some things, and ran some tests, and I just wanted to verify my logic. The tests, with results, and the source code can be found here:
http://www.devnetwork.net/speedTest.php
I just need to verify my conclusions, which are:
1. array_flip()/isset() v.s. in_array()
array_flip()/isset() is faster than in_array() when the test result cannot be found, however, if the test result can be found, it can be much faster. However, this is only considering that the test result is close to the start of the array.
To search for an element at the beginning of the array:
http://www.devnetwork.net/speedTest.php?name=first
To search for an element in the middle of the array:
http://www.devnetwork.net/speedTest.php?name=middle
To search for an element at the end of the array:
http://www.devnetwork.net/speedTest.php?name=last
2. array_flip()/array_flip() v.s. array_unique()
Again, array_flip()/array_flip() twice on the same array is faster than array_unique(). This is an expected result.
Can anyone confirm the validity of these tests, and like I said, the logic?
PHP Timing Issues
Moderator: General Moderators
hmmm..not quite certain, because I just took my first look into the php-sourcecode, but isset seems to take advantage from the fact, that even before it is called it is known if the parameter is a valid variable or not while in_array really searches the array iterating the thing.
However, in_array calls many check-functions when invoked (and that's 10000 times), i.e. _zend_is_inconsistent, while isset is 'just' another case-statement in the main script-execution-loop. After sleeping some hours (it's about 5:00 am here in Berlin) I will take a look in how the parser-tree is generated and maintained - may be that the key lies in there.
However, in_array calls many check-functions when invoked (and that's 10000 times), i.e. _zend_is_inconsistent, while isset is 'just' another case-statement in the main script-execution-loop. After sleeping some hours (it's about 5:00 am here in Berlin) I will take a look in how the parser-tree is generated and maintained - may be that the key lies in there.
Of course that is how array_search() works. The point of the test was to see if when you use array_search(), you could actually get better performance from using the array_flip()/isset() method. I suspected it would be faster over all for the very reasons you mention.
However, in a memory restrictive area, this might not be a good idea to do an array_flip.
However, in a memory restrictive area, this might not be a good idea to do an array_flip.
the curios thing is that php_search_array isn't called for the line isset($myArray['hash']). It does barely more than taking the values from the pre-parsed(!) opline and some value checks. I don't know (yet?) how this is done.....
And the amount of time spent in the check-functions when in_array is invoked is quite huge. There are many functions never called for isset taking most of the time for in_array
And the amount of time spent in the check-functions when in_array is invoked is quite huge. There are many functions never called for isset taking most of the time for in_array