[RFC] array_search_range() function View as Markdown

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]

Hi Sepehr, I've taken some time to review your proposal more thoroughly and
I have some feedback.

1. Is the example in your RFC for a large array of database data an XY
   Problem?
   My first instinct would be to build pagination into the query itself
   rather than process the result set data.

2. Is the example in your RFC for a large array of filesystem data an XY
   Problem?
   Should the script which calls file() actually do the following to
   avoid loading the unwanted portions of data in the first place?

$file = new SplFileObject('access.log');
$file->seek(100000);

$end = 200000;
while (!$file->eof() && $file->key() < $end) {
    if (str_contains($file->current(), 'ERROR')) {
        echo $file->key();
        break;
    }
    $file->next();
}

3. I'm still not convinced that slicing a copy of the array is necessary
   and your proposal seems to be founded on that premise.
   The enormous data payload is already loaded into memory, it just needs
   to be iterated.
   Why can't you use a foreach and conditionally continue/break the loop
   while searching?
   In a scenario which involves an indexed array, a for() loop can be used,
   but for utility a foreach() is more suitable.

if (!function_exists('array_search_range')) {
    function array_search_range(
        mixed $needle,
        array $haystack,
        int $offset = 0,
        ?int $length = null,
        bool $strict = false
    ): int|string|false {
        $count = count($haystack);

        if ($offset < 0) {
            $offset = max(0, $count + $offset);
        }

        if ($length === null) {
            $length = $count - $offset;
        } elseif ($length < 0) {
            $length = $count - $offset + $length;
        }

        if ($length <= 0 || $offset >= $count) {
            return false;
        }

        $position = 0;
        $end = $offset + $length;

        foreach ($haystack as $key => $value) {
            if ($position >= $end) {
                break;
            }

            if ($position >= $offset) {
                if ($strict ? $value === $needle : $value == $needle) {
                    return $key;
                }
            }

            ++$position;
        }

        return false;
    }
}

4. I am not a fan of "falsible return values" because I prefer to null
   coalesce in my code and that is the reason that I try to avoid old native
   PHP functions that return false on an unsuccessful process.
   I can appreciate that you are trying to maintain consistency with
   array_search() - which I almost never use because value-searching an array
   is seldom the most efficient process.

5. Is your proposed function name ideal?
   The coding intention is to hybridize array_search() and
   array_slice(), so shouldn't it be array_slice_search() or
   array_search_slice()?
   The "range" in the function name might mislead developers into believing
   that the function searches for a range of needles.

6. If your coding intention is to meaningfully interrogate portions of
   an enormous array and performance is a concern, then perhaps it is time to
   consider partitioning the enormous array into smaller, more manageable
   chunks or a more searchable map.
   On relatively small arrays, I find this proposal even less compelling.
   Ultimately, I still feel that this RFC is solving a problem that should
   usually be mitigated by an earlier refactor.

7. I find the last line under the "Why This Function Is Worth It" to be
   unusual. "Available now: usable today, not after a multi-month RFC"
   ...well, it's not usable today - it will need to go through the RFC vetting
   process and then get implemented. Your statement feels like unnecessary and
   misleading marketing speak.

While I can imagine there might be a few developers who can benefit from
this RFC, I remain unconvinced that this function would be widely used by
PHP developers.

mickmackusa