Re: [RFC] [Discussion] array_str_contains() for PHP 8.7

From: Date: Mon, 31 Aug 2026 13:46:08 +0000
Subject: Re: [RFC] [Discussion] array_str_contains() for PHP 8.7
References: 1 2 3 4 5  Groups: php.internals 
Request: Send a blank email to internals+get-132400@lists.php.net to get a copy of this message
‪On Mon, 31 Aug 2026 at 14:26, ‫سپهر محمودی‬‎ <sepehrphpr@gmail.com> wrote:‬ > > > > در تاریخ دوشنبه ۳۱ اوت ۲۰۲۶، ۱۶:۳۲ Bruce Weirdan > <weirdan@gmail.com> نوشت: >> >> Hi سپهر >> >> ‪On Mon, Aug 31, 2026 at 12:21 AM ‫سپهر محمودی‬‎ >> <sepehrphpr@gmail.com> wrote:‬ >>> >>> While array_filter with a closure can achieve this, it >>> introduces noticeable overhead in userland due to repeated closure invocations and type checks on >>> every element. >> >> >> If this overhead could be reduced, it would improve the performance of any built-in >> function that calls a user-land closure, not limited to the array_filter + str_contains combo. Have >> you considered solving this problem instead, at least for closures generated by partial applications >> of built-in functions? >> >> -- >> Best regards, >> Bruce Weirdan >> mailto:weirdan@gmail.com > > -------- > > Hi Bruce, > > Thanks for the reply. > > You're right that the closure invocation overhead is not specific to > array_filter + str_contains — it applies to any builtin that calls a > userland callable. However, I see these as complementary rather than > mutually exclusive approaches. > > Optimizing closure invocation for partial applications is a deep change > in the engine (VM loop, call frames, possibly JIT/inline caching), and > would only benefit closures created from first-class callable syntax. > Even then, the userland code would remain more verbose, and the engine > would still have to materialize a call frame per element. > > A dedicated function avoids the call overhead entirely with a few lines > of straightforward C, keeps userland code short and readable, and is > shippable now rather than being tied to a long-term engine project. > > That said, I'd be genuinely interested in seeing a proposal for > optimizing first-class callable invocation — I think it would benefit > array_map/array_filter users broadly. But I don't think it should block > a small, pragmatic stdlib addition. > > Best regards, > Sepehr > Hi Sepehr, In terms of performance, what numbers are we speaking of here? First-class callables have already been significantly improved in recent versions of PHP. How much difference is there from a dedicated function? I would rather see array_filter with a callable than a dedicated function. It's more understandable to me that way. Also, I agree with what others said that I don't consider this code pattern to be exceptionally popular to warrant a dedicated optimized function in the language. I have never found that to be a performance issue in any project. Regards, Kamil

« previous php.internals (#132400) next »