go to bug id or search bugs for
The trivial test script below runs longer than the extpected "instant" execution (lot longer).
This is because the algorithm walks the first argument and looks up the key in every other array supplied as an argument.
Instead it should walk the shortest array given, and look up the keys in every other array.
Maybe this issue or similar ones also apply to other array functions, which perform set operations, but I have not checked the code of them.
Of course the optimization could be done in userland, but that feels not right.
$arr = array_fill(0, 1000000, '...');
$i = 1000;
Add a Patch
Add a Pull Request
we cant start walking the shortest array given, because we first need to know
which elements we need to look in the other arrays, and those are the ones
presesnt in the first array
" returns an array containing all the entries of array1 which have keys that are
present in all the arguments. "
carloschilazo, what you said doesn't make sense.
Intersecting A, B, and C will produce the same result as intersecting C, B, and A, or any other combination of the operands.
Unfortunately, a lot of PHP array functions are known to be extremely inefficient :(
Actually sorry, it does make sense...
But it's easily solvable. Just run the shortest array against the first array (unless they happen to be the same) to get the values, then run the result against the rest of them.
Adding this optimization would make array_intersect_key() much more useful.
Right now, "look up a small selection of keys in a large dictionary of values, and return the looked-up entries" is only efficiently done with a loop, because array_intersect_key() uselessly loops over the dictionary.
If the function iterated over the shortest array (and then looked up each key in the source array), the only thing that would change is the implementation detail that the result no longer maintains the order of the source array.