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
