Optimize array intersection functions for empty operands

[mehmetcansahin]

Avoid unnecessary iteration when an empty operand guarantees an empty result for array_intersect_key(), array_intersect_assoc(), and array_uintersect_assoc().

Includes regression tests covering validation and observable callback/warning behavior.

[kamil-tekiela]

How does it affect performance for the negative case when none of the arrays is empty?

[mehmetcansahin]

@kamil-tekiela Thanks for the review. I reran the non-empty cases using 15 paired processes per scenario and repeated the measurements twice.

For very small arrays, the overhead ranged from roughly 0.5% to 5%, corresponding to only a few nanoseconds per call. With 100 or 10,000 elements, the differences were generally around 1% or less and were not consistent between runs.

Overall, the shortcut adds a small fixed cost to non-empty calls, which becomes negligible as the arrays grow.

[Girgias]

I'm not really a fan of this.

@arnaud-lb could this case be handled in the optimizer? I don't know how accurate MAY_BE_EMPTY_ONLY is and if we can use zend_try_inline_call() to inline an internal function.

[kamil-tekiela]

I also don't like this. You are trading performance, not improving it. IMHO, the more common case is that none of the input arrays is empty, so your PR would actually worsen the performance in the most common case. Maybe it's something for optimizer, but I doubt it's worth optimizing this.

[arnaud-lb]

@Girgias MAY_BE_EMPTY_ONLY() should be accurate and folding the call would work, but the impact maybe limited

[mehmetcansahin]

Thanks for the reviews. Agreed on both counts: the early exit adds a small fixed cost to the common non-empty path, and per @arnaud-lb an optimizer-level fold via MAY_BE_EMPTY_ONLY() would only cover operands that are statically known to be empty, where the impact would be limited anyway. Closing.