Re: Discussion on array_str_contains() RFC and performance benchmarking methodology

در تاریخ پنجشنبه ۱۰ سپتامبر ۲۰۲۶، ۲۱:۴۴ Juris Evertovskis <juris@glaive.pro> نوشت: > On 2026-09-10 14:39, سپهر محمودی wrote: > > > > در تاریخ پنجشنبه ۱۰ سپتامبر ۲۰۲۶، ۰۶:۰۶ 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 Sepehr, > > I've also been following the discussions on the mailing list. > > My read is that Yuya has been the one most welcoming to you. He was > putting in a word for you during the discussion about message phrasing, > providing you some guidance and expressing willingness to involve you in > the i18n work. His openness is visible even now — unlike most of us, he is > trying out your code and giving you feedback. > > Therefore it is a bit sad to see you being angry and dismissive at him in > the latest discussions. I think you are mistaking his short statements for > hostility or gatekeeping. My suggestion: stop throwing away his goodwill. > If an experienced contributor is giving you feedback, you should seriously > consider that there might be something true and useful. > > Regarding the latest discussion I would like to add that admitting lack of > expertise in zend engine (or anything else) is usually not seen here as a > sign of weakness, but of honesty. Many of the readers and voters here are > not experts on every detail either. If someone admits not entirely > understanding what's going on, it gives you a chance to provide > explanations and proof instead of dismissing his benchmarks as useless. > > By the way... > > > Just for your information: someone praised my work who holds a high > position in php-src and whom I truly respect—meaning your opinion doesn't > really matter to me. > > Different open source communities may work differently, but in this one a > reference to an unnamed figure is unlikely to earn you additional respect > or authority. It's best to leave such statements out. > > BR, > Juris > --------- Hi Juris, Thank you for taking the time to write this and share your perspective. You make very fair points, and reading this helped me see things from a better angle. I let my emotions get the better of me in that interaction with Yuya, and I genuinely appreciate you pointing it out. I will reach out to Yuya to clear the air, and I'll keep your advice in mind moving forward. Thanks again for the constructive feedback. Best regards, Sepehr