Re: [PHP-DEV]  Architectural discussion: Composable functional patterns vs. specialized native functions in PHP 's standard library

در تاریخ شنبه ۱۲ سپتامبر ۲۰۲۶، ۰۳:۱۹ Kamil Tekiela <[email protected]>
نوشت:

> Hi Sepehr,
>
> > I believe discussing these fundamental trade-offs will help provide
> clearer guidelines for future RFC proposals and the continuous evolution of
> PHP's standard library.
>
> What are you trying to accomplish with this discussion? What is the
> goal? I am asking because I don't quite understand your questions, and
> this whole topic seems very vague. What are these clearer guidelines?
>
> > Over recent major versions, modern PHP has embraced functional
> programming idioms with first-class callable syntax, arrow functions, and
> generic higher-order operations. While this compositional style
> significantly enhances code expressiveness and flexibility, it introduces
> notable architectural considerations:
>
> I would never consider first-class callables or arrow functions to be
> functional programming idioms. Sure, higher-order functions are
> heavily used in functional programming, but they are just as useful in
> object-oriented programming or procedural programming.
>
> > 1. Performance & Engine Overhead:
> > When composing generic higher-order utilities (such as array/string
> transformers, filters, and mapping operations), what is the acceptable
> threshold for closure invocation overhead and VM context switching in
> performance-critical paths? In what scenarios do we consider this overhead
> significant enough to warrant dedicated, low-level C implementations in the
> engine?
>
> I don't know if that has ever been a major consideration. We consider
> performance on a case-by-case basis. Just like with your recent
> proposal, we ask for some hard evidence. How often is it causing a
> performance bottleneck in real projects? What kind of performance
> improvement would be expected if it were a dedicated function? Etc.
>
> > PHP has traditionally provided rich, specialized functions for common
> data manipulation tasks. How do we balance keeping the standard library
> lean and orthogonal versus providing high-utility, specialized native
> functions that eliminate recurring boilerplate across userland applications?
>
> PHP has never been known as a good example in this regard. The
> standard library is a complete mess (everything but a kitchen sink).
> In recent years, the consensus has been that we only add functions
> that provide behaviour which is either impossible or very difficult to
> emulate in userland, or so ubiquitous that it deserves a dedicated
> function. For example, `str_contains` was added to simplify `strpos
> !== false`, `array_first` was added to simplify
> `$array[array_key_first($array)]`, `array_is_list` was added to expose
> functionality which was quite difficult to emulate in userland. All of
> these are examples of very common patterns that were used verbatim
> sometimes hundreds of times in a single project.
>
> > 3. Performance Benchmarking & JIT Optimization:
> > As the JIT compiler matures, should the engine rely more heavily on JIT
> optimizations to inline higher-order functional patterns, or will
> specialized native C functions always remain the preferred standard for
> mission-critical operations?
>
> JIT is only useful for highly specialised applications. For most
> applications, such as websites, JIT doesn't offer a lot of benefits.
> But besides that, I don't really understand this question. It seems
> like a non-sequitur to me.
>
> I won't even attempt to answer the last question, as it seems so vague
> to me; one could write a whole book about it and still have more to
> add.
>
> Regards,
> Kamil
>

----------

Hi Kamil,

Thank you for the direct feedback. I appreciate you pointing out the
vagueness in my initial questions; that was not my intention, but I see now
that I was approaching the topic from too high an abstraction level.

To clarify my goal: I am not looking for a philosophical treatise, but
rather to understand the practical "threshold" the core team uses when
deciding whether a common pattern (like string searching within an array)
should be implemented as a specialized native function versus leaving it to
userland composition (like array_filter with a closure).

You mentioned that performance is considered on a case-by-case basis with
hard evidence. That is exactly where I want to focus.

Instead of discussing generalities, I will prepare a concrete benchmark. I
plan to compare:
1. The overhead of common compositional patterns (e.g., array_filter +
str_contains inside a closure).
2. The performance of a potential specialized native implementation (e.g.,
a hypothetical array_str_contains).

My goal is to provide the "hard evidence" you mentioned, showing
specifically where the overhead of closure invocation and VM context
switching becomes a measurable bottleneck in common real-world scenarios.

I will follow up with the results once the benchmarking is complete.

Regards,
Sepehr