Re: [RFC Update] array_str_contains(): Removal of performance benchmark tests

در تاریخ چهارشنبه ۱۶ سپتامبر ۲۰۲۶، ۱۶:۴۱ Larry Garfield < larry@garfieldtech.com> نوشت: > On Tue, Sep 15, 2026, at 6:05 PM, سپهر محمودی wrote: > > در تاریخ چهارشنبه ۱۶ سپتامبر ۲۰۲۶، ۰۰:۵۵ Larry Garfield > > <larry@garfieldtech.com> نوشت: > >> On Tue, Sep 15, 2026, at 10:53 AM, سپهر محمودی wrote: > >> >> Hi internals, > >> >> > >> >> It has been 3 days now and no one has agreed on running the > benchmark tests for my function. > >> >> > >> >> If there is no agreement on keeping the benchmarks within the next 2 > days, the benchmarks will be completely canceled for my function. > >> >> > >> >> I look forward to hearing your valuable feedback. Also, this thread > is not just for the benchmarks of this function; you can share any valuable > feedback or thoughts you have regarding my function in this thread. > >> >> > >> >> With respect, > >> >> Sepehr > >> > >> I'm pretty sure the reason no one has looked at your benchmarks is no > one supports this function. I don't believe I've seen a single person > agree with you that it's useful. You have just been flooding the list with > messages assuming this function will be the greatest thing since sliced > bread, across multiple threads for no apparent reason. You've already been > advised, both on list and off, on an alternate approach for your specific > use case. It seems obvious to me that PHP-Internals is just not interested > in this functionality. Period. > >> > >> Whether you're using AI or not, your posts are not helpful or > constructive and people are tired. > >> > >> It's OK to have a proposal rejected. Even very experienced long time > contributors have ideas declined early on. It is part of the process, and > that's OK. Pushing and pushing and pushing after it's clear that it's not > going to happen is not a part of the process. It's just a waste of > everyone's time. > >> > >> Please stop wasting everyone's time. > >> > >> --Larry Garfield > > > > --------- > > > > Hi Larry, > > > > I need to clarify a few points regarding your email. First, you > > initially set providing benchmarks as a primary condition for this RFC. > > Later, in private, you told me they weren't necessary. Now, claiming > > that these benchmarks are invalid or non-existent completely > > contradicts your own initial request. > > This is an outright lie. > > I previously stated that if your argument for a feature is performance, > then it needs benchmarks to demonstrate that performance. > > Weeks later (a few days ago), you emailed me directly asking for help with > CI issues on your PR. > > This was my response: > > --- > Hi Sepehr. > > I... don't know why you're asking me for help on this. I am very open > that while I do a lot of design work for PHP, actually working on the > codebase is not something I'm good at. I barely manage to read a few parts > of it, and don't know the first thing about why FreeBSD builds or such > would die. > > This would be a question better directed at the list, or just ask for help > on the PR itself. > > That said, I am also not sure why you're still pushing for that function. > The feedback has been universally negative. I'd lay good money that the > RFC never passes, no matter what your benchmarks say. As I said weeks ago, > if your particular code base is such that this is your bottleneck, then > first congrats on having a very efficient application, and second, it's > time to write a tiny extension for just your project. > --- > > This is not saying "benchmarks aren't necessary," "benchmarks are > invalid," or "non-existent." It's saying "stop wasting your time and > everyone else's, no one wants your RFC." That is still what I am saying. > (And looking at the RFC on the wiki, I don't actually see benchmarks > listed.) > > > As for performance, I’ve already conducted a real-world usage analysis, > > and the JSON results are documented in the RFC. They clearly show that > > this function outperforms the alternatives you suggested. > > The alternative I suggested, weeks ago and in the email above, is writing > your own tiny extension to provide the C function you have already > written. Its performance, whatever it is, should be identical regardless > of whether it's in stdlib or your own extension. Your response here is > completely inaccurate and grossly misrepresents my very clear statements on > the matter. > > > Given the documentation and the results, I cannot accept your > > assessment that the benchmarks are invalid. The performance of this > > function is proven. > > Once again: > > 1. I never said they are invalid. > 2. There are no benchmarks on the RFC listed on the RFC index page > (although the formatting is broken) > 3. What I said is that no one is interested in this proposal, regardless > of its performance, so please stop wasting our time and yours. > > If you are unable to engage honestly and without misrepresenting what > others have said on this topic, then please remove yourself from the > mailing list. > > --Larry Garfield > ------- Hi Larry, First, I have to point out that you told me to ignore benchmarks because this function had no place in the core, yet now you claim it was a misunderstanding. Second, my RFC page has received a significant number of views, which again contradicts your point. Third, please stop trying to use language that leads the conversation in the wrong direction. Everyone is reading this email, and I have one question: Does anyone here actually dislike my contributions to php-src???? With great respect to everyone and Mr. Garfield, Mahmoudi