Hello 2025-08-29 at 15:12, Tim Düsterhus <[email protected]> wrote:
> Hi > > On 8/29/25 04:42, Morgan wrote: > > Another part of the argument is "complexity", as brought up in the > > original proposal. I notice that the offered implementation of this > > function relies entirely on zend_compare(). > > I'm not finding the word “complexity” in https://wiki.php.net/rfc/clamp > or https://externals.io/message/115050. Can you link to the message you > are referring to? > > > reasons. The extra complication may not be worth it if there are only > > two or three values being compared (long and double are the first types > > zend_compare tries). > > I'm positive that the benchmarks will answer that question. > > Best regards > Tim Düsterhus > I back-ported "not cost-effective when called multiple times" from the clamp v1, I think its author meant "compared to user-land implementation using min(max())" So I just did this benchmark: https://github.com/kylekatarnls/clamp-perf-test/actions/runs/17546601109/job/49829393835 (following Tim's advice to use hyperfine for it). Summary is: php clamp.php ran 1.06 ± 0.02 times faster than php ternary.php 1.42 ± 0.03 times faster than php min-max.php Which means if everything is correct, then the current native implementation proposal is barely faster than a user-land function using ternary implementation. Using a user-land function and min(max()) is 42% slower. (See the files at the root of this repo: https://github.com/kylekatarnls/clamp-perf-test) Those numbers might have been better in the first implementation (which supported only int and float and it had no special case handling for NAN, so I guess it was even a bit faster this way). Anyway, I think the speed is probably not the main reason why we should add it. Maybe I would rather phrase the above result this way: - User-land implementation for clamp using ternary is notably faster than min(max()) user-land implementation -> but still the difference shouldn't be a concern for most people. - With the native implementation, you get (for no extra speed cost): -> NAN handling -> verification than min < max -> a standard way (framework/application can drop their own implementations and converge to the one propose by the language which will also be pretty similar with most implementations in other languages) So I guess I should arrange the note about cost-effectiveness, or maybe drop it all together.
