در تاریخ شنبه ۱۲ سپتامبر ۲۰۲۶، ۰۳:۱۹ 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
