Hi
On 9/4/26 16:47, Larry Garfield wrote:
And that is also independent of whether it’s stdlib or a language
feature (such as erased generics, which are fast, but have language
design arguments against).
Or in short: Performance is a property of the implementation, not a
property of the feature.
I think we're saying almost the same thing, from different directions.
Performance alone is not an argument for a feature, but can be a contributing
factor. Performance alone MAY be an argument against a feature, depending on
the feature, but there are still many other factors to consider.
The “almost” does some heavy lifting there, I believe.
I disagree that performance should be a contributing factor to whether
or not a proposal is good, because performance is a property of the
implementation and implementation is not what is being discussed and
voted on as part of the RFC process.
knowing the relative performance difference is a useful data point to have
I disagree, because it rarely is an apples to apples comparison (bad
userland vs good internal implementation and vice versa) and it ignores
other possible solutions to fix a performance problem, for example
improving the Optimizer to detect specific patterns and to transform
them into equivalent, but faster code.
Using the featured RFC which proposes a function that effectively just does:
array_filter($values, str_contains(?, 'foo'));
as an example, an alternative improvement to investigate would be
replacing calls to `array_filter()` with PFA by a foreach loop:
$result = [];
foreach ($values as $key => $val) {
if (str_contains($val, 'foo')) $result[$key] = $val;
}
similarly to the `array_map()` transform that is already included in PHP
8.6.
Best regards
Tim Düsterhus
