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

From: 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 -----------------------------

« previous php.internals (#132472) next »