Re: Discussion on array_str_contains() RFC and performance benchmarking methodology
| From: | youkidearitai | Date: | Thu, 10 Sep 2026 12:04:43 +0000 |
| Subject: | Re: Discussion on array_str_contains() RFC and performance benchmarking methodology | ||
| References: | 1 2 3 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-132472@lists.php.net to get a copy of this message | ||
2026年9月10日(木) 20:40 سپهر محمودی <sepehrphpr@gmail.com>:
>
>
>
> در تاریخ پنجشنبه ۱۰ سپتامبر ۲۰۲۶، ۰۶:۰۶ youkidearitai
> <youkidearitai@gmail.com> نوشت:
>>
>> 2026年9月10日(木) 10:07 سپهر محمودی
>> <sepehrphpr@gmail.com>:
>> >
>> >
>> > Hi everyone,
>> >
>> > I hope you're all having a great week.
>> >
>> > I’ve been following the discussions and recent feedback regarding the
>> > array_str_contains() RFC closely. Performance and speed comparisons have come up as a key point,
>> > especially around whether a dedicated internal C implementation provides sufficient value compared
>> > to a userland foreach loop.
>> >
>> > I'd love to open up a constructive and transparent discussion around the
>> > benchmarking methodology we're using here. Some of the initial numbers shared recently
>> > don't seem to reflect real-world scenarios or different data profiles (like varying array
>> > sizes, early exits vs worst-case lookups, UTF-8 strings, and compiler optimization flags like -O2 /
>> > -O3).
>> >
>> > Before drawing final conclusions on performance, I think it would be great if we could
>> > align on:
>> > 1. The exact benchmark scripts and test datasets we should use to evaluate this
>> > fairly.
>> > 2. The compilation environment and flags used for generating these metrics.
>> > 3. Where the potential overhead in the current C implementation is coming from and how
>> > we can optimize it together.
>> >
>> > My goal has always been to make PHP more expressive and efficient for everyday
>> > developers. I welcome any suggestions, insights, or benchmark reproductions from the community so we
>> > can evaluate this RFC based on solid, agreed-upon data.
>> >
>> > Thanks for your time and feedback!
>> >
>> > Best regards,
>> > Sepehr
>> >
>>
>> Hi Internals
>>
>> For your reference, I have attached the benchmark diff files. (commit
>> hash is 4982bf45f4786faaa198558dd619f8a4d59e25f0)
>> - .diff
>> - .exp
>> - .log
>> - .out
>> - .php
>> - .phpt
>> - .sh
>>
>> I can not find definite improve performance.
>> (My PC: WSL Ubuntu 24.04, Ryzen 7 7735HS, 32GB RAM)
>>
>> I don't familiar with Zend Engine's performance, However I think
>> function's performance improvement is limited.
>>
>> Regards
>> Yuya
>>
>> --
>> ---------------------------
>> Yuya Hamada (tekimen)
>> - https://tekitoh-memdhoi.info
>> - https://github.com/youkidearitai
>> -----------------------------
>
>
> Hi Internals,
>
> Thank you all for the time and effort invested in this discussion.
>
> Regarding the benchmarks provided by Yuya, I must address two critical issues:
>
> 1. The provided implementation does not even build in my environment. It is scientifically
> impossible to derive any performance conclusions from code that fails to compile.
>
> 2. Given your own admission of limited familiarity with the Zend Engine internals, the
> methodology applied here lacks the necessary technical rigor for a valid assessment.
>
> I am more than willing to engage with constructive, reproducible, and engine-aware performance
> analysis. However, as it stands, the provided material is effectively contentless and does not offer
> a basis for a technical evaluation.
>
> Best regards,
>
> Sepehr
>
>
Hi
PLEASE UNZIP ATTACHED FILE. YOUR CODE.
Regards.
Yuya
--
---------------------------
Yuya Hamada (tekimen)
- https://tekitoh-memdhoi.info
- https://github.com/youkidearitai
-----------------------------