Re: [DISCUSS] Should RFCs for new functions include a userland polyfill/reference implementation?
| From: | سپهر محمودی | Date: | Fri, 04 Sep 2026 13:43:48 +0000 |
| Subject: | Re: [DISCUSS] Should RFCs for new functions include a userland polyfill/reference implementation? | ||
| References: | 1 2 3 4 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-132421@lists.php.net to get a copy of this message | ||
در تاریخ جمعه ۴ سپتامبر ۲۰۲۶، ۱۶:۳۴ Larry Garfield
<larry@garfieldtech.com>
نوشت:
> On Mon, Aug 31, 2026, at 9:57 AM, Tim Düsterhus wrote:
> > Hi
> >
> > On 2026-08-25 17:34, Larry Garfield wrote:
> >> And it would also give us a target to benchmark against to see if
> >> putting it in C really has a performance benefit.
> >
> > I believe performance should not be a factor in deciding what should be
> > part of the stdlib and what should not: Performance is a moving target
> > and what might be true today might no longer be true tomorrow - with
> > folks generally having wildly incorrect assumptions about what actually
> > is “slow”.
> >
> > Once we add something to the stdlib we need to maintain it for the next
> > 15+ years. (Broad) usefulness and good API design must be the deciding
> > factors for whether something should be in the stdlib or not [1].
>
> I agree that good API design should be the primary factor. However, I
> disagree that performance is a non-factor. Yes, performance comparisons
> will shift over time, but that doesn't make it unimportant. It is one
> useful data point among many.
>
> If, to use the current example, benchmarking shows that
> array_str_contains() is 50% faster in C than in user-space, that's a very
> different conclusion than if we find it is 0.5% faster. The former
> provides an argument for inclusion, though obviously not a slam dunk (as
> overall API design is a larger factor). In the latter case, we know that
> performance is a non-argument and can be dismissed.
>
> We stress over the performance impact of certain generics approaches, we
> spent a lot of time thinking about performance implications for hooks, or
> PFA, or pipes. stdlib functions should not be exempt from that
> consideration. They should just be considered appropriately and in context.
>
> --Larry Garfield
>
--------
Thanks, Larry. I agree that performance is a relevant data point.
I have already conducted a real-world usage analysis, and the RFC now
includes both the summary table and a link to the complete JSON dataset.
I will also prepare a benchmark comparing the C implementation with
representative userland implementations (such as foreach loops and
array_filter-based approaches) across different array sizes and match
positions, and share the results.