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.

در تاریخ پنجشنبه ۱۰ سپتامبر ۲۰۲۶، ۲۱:۴۴ Juris Evertovskis juris@glaive.pro
نوشت:

در تاریخ پنجشنبه ۱۰ سپتامبر ۲۰۲۶، ۰۶:۰۶ 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