On Tue, Sep 15, 2026, at 6:05 PM, سپهر محمودی wrote: > در تاریخ چهارشنبه ۱۶ سپتامبر ۲۰۲۶، ۰۰:۵۵ Larry Garfield > <[email protected]> نوشت: >> 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
