@velkuns @dgoosens The `BazInterface::class` case will never match, though.

@Crell That example is broken, since trying to assign a value to `$account_status` will always fail with a TypeError.

@edorian @Crell @dseguy And besides the array construction (and destruction) being extremely expensive, touching every element of the "source" array to copy it to the "target array" *clearly* can't be cheaper than `?:` which short-circuits and doesn't need to look at the later elements when it already found a non-zero value.

@edorian @Crell @dseguy The allocations are not even the worst thing. It's inserting the entries one-by-one into the freshly allocated array. That alone makes up ~13% of the entire runtime of the script (17% of the entire time is spent in the ADD_ARRAY_ELEMENT OPcode, the 4 percentage points difference is the other stuff the OPcode does besides the actual insertion).

@Crell @dseguy Because that is significantly less efficient?

@pollita @GuillaumeRossolini @ramsey Except C++, I guess 😜

https://godbolt.org/z/o48rcvGzz

#include <iostream>

struct Foo {
void operator++() {
std::cout << "pre\n";
}

void operator++(int) {
std::cout << "post\n";
}
};

int
main(void) {
Foo f;

f++;
}

@ADoebeling https://www.godaddy.com/de/legal/agreements?

@ramsey Performance improvements are generally considered "features" and often result in more significant changes. It does not seem right to me to make this an exception.

Also, it's probably a good thing to give folks more reason to update to newer PHP versions instead of staying on whatever old have they have 😃

@nielsdos @ramsey Within namespaces it's important to point out that this optimization only happens with fully-qualifying the call to `count()`. Either as `\count()` or via `use function count;`. Otherwise a `count()` function could exist in the namespace.

@ocramius @come @pollita There were some improvements, but a plain `foreach()` loop is still going to beat `array_map()`. And trying to optimize `array_map()` into a loop is likely going to be hard, because of the semantics around scoping and type checking of the closure (both parameter and return types).

@JosephLeedy @halibut For me it's the `=== []` variant that is most explicit in intent.

That's why I proposed a PR to improve the performance of it (pending a second review), making it the fastest option:

https://github.com/php/php-src/pull/18571

"""Checking whether an array is empty with a strict comparison against the empty array is a common pattern in PHP. A GitHub search for "=== []" language:PHP reveals 44k hits. From the set of !$a, count($a) === 0, empty($a) and $a === [] it however is also the slowest option."""

https://github.com/php/php-src/pull/18571

This is a great example of how you should write whatever you find most readable and maintainable, and let us worry about efficiency. Wtih this PR, the "slow" approach becomes a "fast" one.

@halibut In that case it's possible that OPcache optimized away some of the operations (depending on how “performed the test” looked like exactly).

I had tested with https://gist.github.com/TimWolla/060dc67156949b6b109158b2bd677ca8, making sure that I use all values and not using a compile-time created array and then I benchmarked with hyperfine as explained in

https://tideways.com/profiler/blog/how-we-use-hyperfine-to-measure-php-engine-performance

I could confirm that `=== []` was the slowest, I believe in earlier PHP versions it was the fastest. But `empty()` for me was faster than `count()`.

We moved clone_with_v2 to "under discussion" now.

#rfc: https://wiki.php.net/rfc/clone_with_v2
Externals: https://externals.io/message/127353

Let me know what you think!

While I don't have many use cases for it I found the idea to be quite neat and that it rounds out #php.

Let's see if we can finish what Máté https://github.com/php/php-src/pull/9497#issuecomment-2732775806 started :)

@halibut This does not match what I'm seeing. How does your benchmark script look like? Did you make sure that you actually measured what you intended to measure? Also, what PHP version did you test with?

@beberlei @heiglandreas @sebastian @theseer @Tideways From one of my own projects (a CRUD web application): An average request spends ~30% of its time doing IO. SQL queries are mainly SELECT statements hitting a PRIMARY KEY and result in sub-millisecond query times.

It looks like this is the month for TLS benchmark articles, 7 days after the publication of "The State of SSL Stacks" article on haproxy.com, @djc released a very interesting article about the performances of rustls. https://www.memorysafety.org/blog/rustls-server-perf/ .

@cscott @Edent But expecting issues to magically get fixed when not reported or expecting the PHP maintainers to monitor the Wikimedia issue tracker is a broken expectation that is hurting everyone.

@cscott @Edent The PHP project, or more specifically the DOM maintainer, which is an individual doing that in his free time, knows about issues that folks run into in the real world, allowing him to prioritize fixes or provide insight in why a bug might not actually be a bug.

And you get a link you can reference in your code, hopefully making it easier to remove the workaround once the issue in PHP is fixed, because these workarounds can't be free to you (e.g. from a maintenance perspective).

@cscott @Edent Not a native speaker of English, I don’t understand the meaning “don’t count your chickens” idiom and a web search was not helpful in understanding what this might mean here.

Establishing some process to make sure that every workaround you implement also results in an issue filed in the php-src would definitely make the process much easier for both sides.