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

در تاریخ پنجشنبه ۱۰ سپتامبر ۲۰۲۶، ۱۵:۳۷ youkidearitai < youkidearitai@gmail.com> نوشت: > ‪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 > ----------------------------- > Mr. Hamada, If you lack a solid grasp of Zend Engine internals and core data structures like zval—which is the very backbone of PHP’s C runtime—it feels like you are simply relying on an AI assistant rather than technical understanding. Without mastering zval and Zend memory handling, working at this level in C is effectively crippled. To answer your question: I am testing this on high-end industrial 64-bit hardware, and your provided files still completely fail to build. Perhaps you should tell your AI to think a bit harder before generating patches and benchmarks.