در تاریخ دوشنبه ۳۱ اوت ۲۰۲۶، ۱۶:۳۲ Bruce Weirdan <[email protected]> نوشت:
> Hi سپهر > > On Mon, Aug 31, 2026 at 12:21 AM سپهر محمودی <[email protected]> > 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: > [email protected] > -------- 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
