Re: [PHP-DEV] [RFC] array_search_range() function

On 18 August 2026 19:32:08 BST, "سپهر محمودی" <[email protected]> wrote:
>
>Your point about the polyfill was genuinely brilliant. It actually made
>
>me realize I was overcomplicating things. I went ahead and added a
>
>“Polyfill” section to the RFC


The polyfill you've added to the RFC uses array_slice, so has to copy part of the array into new memory, and potentially iterate the array elements *twice* (once in array_slice, and again in array_search).

The polyfill I included in my last email just loops over the array once, and stops when either a match is found or the limit is reached. That's what I mean by "memory-efficient": there is no need to make a copy of any part of the array.

That's basically the same algorithm that you'd need to implement in C, if you didn't build a reusable ArraySliceIterator. (I note that the implementation you've linked doesn't actually compile on any of the CI targets.)

There might be some performance gained just by looping in C rather than PHP, but the optimisations I can see being more significant are taking advantage of the memory layout to jump quickly to the initial offset:

- Since PHP 7, some PHP arrays are stored "packed" - that is, with the elements sequentially in memory - so you can calculate the memory position of any element without iterating the array at all. You can see that in action if you look up the source code for array_slice, and both ArraySliceIterator and array_search_range could take advantage of it. 

- For a hash-based array, you might still need to iterate to find the bucket with the initial offset; but an ArraySliceIterator could then cache the memory location of that bucket, so that iterating the same slice a second time was much faster.

None of this changes my opinion that the general-purpose ArraySliceIterator is a better feature for the language than a single array_search_range function that doesn't build towards any future scope.

Regards,

Rowan Tommins
[IMSoP]