The upcoming PHP 8.4 release will include the brand-new feature “property hooks”, a mechanism to add logic to a class property when read from or written to. One benefit of this feature is that you do not need to protect property access with a private property and public getter/setter methods anymore.

You can find out how this feature works in the RFC and other places, but in the spirit of this blog we want to focus solely on the performance implications.

We would like to know if there is a noticeable effect on performance when we design applications from scratch with public properties backed by hooks and without getters/setters? 

Or, more drastically, is it a winning strategy to leave the getters/setters behind, never look back, maybe even rewrite our existing applications?

From a macro-perspective, the answer is no.

Looking at a call graph for our own Transaction settings list view, we see that even when rendering a large amount of 100 Doctrine entities, calls to their getters account for a minimal amount of time in the request, fractions of milliseconds.

Changing the code to use public properties and property hooks will not significantly alter the application performance.

Nevertheless, it’s interesting to dive into a benchmark of property hooks vs. getter/setters, to understand if both approaches have a similar performance. If they do, it is unnecessary to consider performance, when deciding between the two. And that reduces mental load.

Establishing Baseline: Public Property vs Getter/Setter

It’s a well-known fact that public property access is faster than going through a getter method to access a private property. We can set up a benchmark with hyperfine to calculate that difference to be roughly 60% slower for getters/setters with these code examples:

Public Properties are rarely used, despite their speed, due to the importance of other concerns:

1. Information Hiding: Using getters/setters allows us to avoid exposing how the data is stored in the class.
2. Changing a public property to a getter in the future requires numerous refactorings, or the use of magic __get methods, Both of these are unnecessary risks that can be avoided by using getter/setter methods from the start.

With property hooks, both concerns can be addressed by adding property hooks, when the access to the public property should be restricted in any way.

Comparing Public Property with Hook vs. Getter

So, let’s add a property hook example for reading and writing that resembles the logic of the getter and setter methods.

Both approaches are very close to each other with only a 9% performance difference.

So the result is clear: Performance should not be a concern when you decide to use either properties with hooks or getter/setter methods for accessing properties on classes. This is especially true because, as we saw at the beginning, property access usually accounts for only a small part of the total request time.

The case for benchmarking: Hook performance improvements during PHP 8.4 alpha

While it is important to know that both approaches have similar performance characteristics, micro-benchmarking new features vs. old alternatives serves another purpose. 

We wanted to write this blog post directly after property hooks were merged because from our experience we expected the conclusion to be that performance is not a concern.

But when we ran the numbers with an early PHP 8.4 alpha, we realized that property hooks were about 200% slower than getters. 

Turns out, the implementation of property hooks was not optimal, and we reported this behavior to the property hook feature authors Ilija and Larry. The fix required another amending RFC, but was approved by PHP RFC voters, leading us to the performance we have now during the PHP 8.4 release candidate phase.

Sometimes, performance is the primary requirement when you are picking a third-party library to solve a task in your application. 

For CPU intensive work, there are often similar alternatives that you can choose from:

• Serialization with Serde, JMS Serializer or others
• Crawler Detection with jaybizzle/crawler-detect or matomo/device-detector
• Dates and Times with nesbot/carbon or cakephp/chronos

To find out which one of them is more performant for your use-case, you can set up an experiment with microtime/hr_time calls and run them against each other.

But: this provides fewer insights than running your tests directly with a Profiler such as XHProf or Tideways!

Comparing Performance of PHP Crawler Detection Libraries

For the use-case of crawler detection inside Shopware, I recently wondered which library to use when trying to detect if the current request is made by a crawler.

Naturally, you would say, let’s use PHPs native get_browser function. But there are also specialized libraries such as jaybizzle/crawler-detect or matomo/device-detector. 

Consulting their respective documentations, I came up with the following code snippet to test their speed:

I searched for different sources of example user-agents and compiled a list of roughly 2700 ones, then generated a Tideways profiling trace from the CLI for the snippet with:

Here is the trace.

The result disqualifies PHPs internal get_browser because it is pretty slow. 

Both userland libraries are within 12% of each other, with 767ms vs. 685ms.

That gives me confidence that either one of them is quick enough to be used in a request testing just the one user agent of the current user.

To verify this, I generate another callgraph where each is testing the same single HTTP header and get surprised. Now matomo/device-detector is 10x slower than jaybizzle/crawler-detect.

Here is the trace.

The reason is that matomo/device-detector initializes a regular expression once, calling AbstractParser::getRegexes, which takes roughly 18ms. The actual test of the user agent against the initialized regex is quite fast. In comparison, jaybizzle/Crawler-Detect code-generates their regex as a build step.

As a result, I’d rather pick jaybizzle/crawler-detect for my use-case of detecting a crawler in a single request, as 2ms is acceptable but 20ms is already a bit too much.

This does not disqualify matomo/device-detector in general, it could primarily be used inside a background job when analyzing many user agents at the same time, so this library might not be optimized for my use-case.

When using MySQL and InnoDB you will inevitably run into lock timeouts sometime, somewhere. 

We have recently started seeing this with some of our Shopware 6 customers in their storefronts or worker queues, so I was reminded to go back to 2017 in our codebase when we put a fix in place.

In our case, this happened on tables that were constantly written to from many different sources in the code base. But it only happened once every few hours or days in worker or cron jobs, and usually fixed itself by retrying the task, or even the function call itself at the code level.

In Tideways you’ll get a notification about the lock timeout as an exception, and you’ll see that it happens sporadically. In the case represented in the following screenshot this has happened a few times in the last days, always around 21:00:

One downside to MySQL lock timeouts is the default wait time: 50 seconds! This is a time where your web server, workers or cron jobs are idle. In our case when a backlog happened it quickly spiraled out of control and all workers suddenly had to wait.

Dealing with this timeout can make the difference from your application failing from the backpressure of requests or tasks that do not get processed fast enough and ties into decreasing timeouts across the board, a topic that we have blogged and podcasted about before.

If your code reaches the wait timeout failure and stops execution completely, a 1-second wait should be fine. Our write heavy worker tasks therefore change the timeout at the beginning of each task:

$this->connection->exec('SET innodb_lock_wait_timeout=1');

Or, you can change this setting directly in the MySQL server so that it doesn’t have to be a concern of your application.

If the occasional lock timeouts are acceptable and your application can recover from them, then this is a much simpler solution than re-architecturing your data write access to avoid the locks altogether.

PHPs compiler and bytecode cache OPcache not only cache the compile step from PHP source code to virtual machine bytecode, they also include optimizations that can produce faster bytecode:

For example PHP can:

• optimize empty functions away. You can see this in a Callgraph Profiler when the function is not appearing in the result. 
• already compute the result of constant compile time expressions into their result, for example 1 + 1 as 2.
• replace calls to often used functions with logic directly in the VM to avoid the function call overhead of the engine. We wrote about these compiler optimized functions on this blog before.

For PHP 8.4 Tideways sponsored the work of our colleague Tim to add another compiler optimization for the function sprintf().

If you call the function with a format string containing only %s placeholders the engine will compile the call to sprintf() directly into the equivalent string interpolation, removing the overhead of the function call and avoiding repeatedly parsing the format string.

Taking an example from our code-base, we build many of our Redis cache keys using sprintf() and a pattern like this:

private function key(string $type, int $identifier): string
{
 return sprintf('last_ts_%s_%s', $type, $identifier);
}

With this optimization, the engine will automatically rewrite it to look like this code:

private function key(string $type, int $identifier): string
{
  return "last_ts_{$type}_{$identifier}";
}

This optimization will happen automatically during compilation of any PHP script and requires no work on your end.

We quickly followed up on this initial optimization with another pull request to add support for the %d placeholder.

Support for just these two placeholders allows the optimization to apply to more than 90% of the format strings encountered in the landing page of PHP’s Symfony Benchmark.

Given the widespread use of sprintf() in common PHP code (616 times in Tideways own backend code) this is an optimization that will make a small but significant contribution for the overall PHP performance.

With this optimization in mind, it also enables you to write or rewrite string manipulation code that is already performance sensitive to use sprintf() for better readability without making it slower.

This is the story of the manufacturing of seven-league boots for a function that is responsible for processing XML/HTML data in the PHP library. Optimizations in the PHP standard library, like here in ext/dom, have the potential to speed up the performance of applications significantly by an upgrade to the current PHP version. I don’t want to spill the beans right at the beginning but the performance optimization from PHP 8.2 to PHP 8.3 in percent is … no, I’ll show you later to keep up the suspense.

Let’s start at the beginning and work our way through the story of this particular bugfix, which began in 2019 when I was working on the RFC “DOM Living Standard“. I stumbled upon this performance problem which was brought to my attention by a Wikimedia programmer and thereupon created a bug report with “reproduce case“. This resulted in Niels Dossche authoring a performance fix.

What this performance improvement means can be seen in a Profiler such as Tideways. Using the new #[WithSpan] feature for the Timeline of the Tideways Profiler it is possible to see the duration of calls to certain functions of your codebase. I modified the code for reproduce case to include the attribute like this:

You can see in the Profiler that the “addParagraphs” function becomes slower with each call even though it does exactly the same and should accordingly be about as fast every time. 

Furthermore, by looking at the  “Callgraph”, it becomes possible to exactly pinpoint the place where the application is slow: The DOMNode::appendChild function taking 91% of the time.

PHP 8.2 Callgraph

PHP 8.3 compared to PHP 8.2 makes the performance improvement visible:

It sounds like magic was involved but the 94% performance increase was achieved by an optimization in the PHP standard library (in this particular example in ext/dom). The potential to make many applications faster by upgrading to the latest PHP version or at least a more recent version is sometimes underestimated.

90% of the time when I explain how the stat cache works in PHP, people are surprised because they expected it to work differently. It was invented to solve a very limited problem when you call several file system related operations on the same file in quick succession.

Why should you know how it works? Because sometimes you need to work around the cache with the clearstatcache() function to get PHP code to run without errors.

Historical Context

Let us start at the beginning. What is stat? It is a C-level API call to the filesystem to query the metadata of a file, such as user, group, readability, writability, size, modification times. And PHP wraps this call with its own function that is also called stat and also uses this function internally in different places.

Historically, this has been an expensive operation to perform.

A number of PHP functions need this, PHP’s stat itself of course, but also file_exists, is_readable, is_writable and many more.

PHP’s stat cache

That is where the PHP stat cache comes into play: It caches the result of low-level stat operations. With one important caveat. The cache only caches this information for exactly one file. The last one that used the cache. And it caches this on the request-level, it is not a cross-request or process cache like OPcache.

This means that if PHP performs a low-level stat operation on a file and it wasn’t in the stat cache before, it will overwrite the previously stored stat data for the previous file.

How is the stat cache implemented?

If the stat cache were to be implemented in PHP, it would look something like this:

<?php
class FileStat
{
    private static string $CurrentStatFile;
    private static PhpStreamStatBuffer $ssd;

    public function stat(string $path)
    {
        if ($path === self::$CurrentStatFile) {
            return self::$ssd;
        }

        $statBuffer = new PhpStreamStatBuffer(stat($path));
        self::$CurrentStatFile = $path;
        self::$ssd = $statBuffer;

        return $statBuffer;
    }
}

You can find this code in “ext/standard/filestat.c” in “php_stat” function.

Conclusion

So what does this tell us about the stat cache? Is it useful? It is hard to tell, especially on modern Linux and with SSD disks. But I didn’t measure, a topic for future research.

But if you want to make use of it, remember that you cannot interleave operations on multiple files, they would cause the cache to be overwritten.

You’ll find the complete list of functions that use the stat-cache in the documentation of the clearstatcache() function.

In this blog post I want to share a story of a performance bottleneck using the filesystem that we experienced in our development setup.

In the Tideways backend, we have a simple homegrown database migration tool that scans a directory for .sql files and applies them if not already done. It is a very old piece of code that I used since before the times of doctrine/migrations. It is much simpler but works for us.

To avoid the development system running with an outdated schema after git pulling commits with SQL schema changes, this database migration tool checks for missing migrations to apply on every single request (in the development environment).

This check only requires 1 SQL select to fetch the already applied changes from the changelog table and one glob to fetch the list of all schema files. Should be quick and straightforward! Right? The high-level code looks something like this:

Looking at the callgraph however, shows a bottleneck in file_get_contents:

We have 450 SQL migrations already, and for checking the current status the content of each SQL file is loaded into memory in DbDeploy::getAllMigrations().

The MigrationStatus::hasOutstandingMigrations() method shown above does not need the SQL file contents, so we can refactor the code to call file_get_contents at the last possible moment.

This lazy loading pattern is widespread when it comes to database operations but also makes sense for the file operations here. The virtual filesystem of our development environment, which makes file operations considerably slower than with a non-virtual filesystem, adds extra time to these operations.

After refactoring away the file_get_contents calls from the DbDeploy::getAllMigrations() method into Migration::getSQL() that is only called directly before executing the changes, we see improvements.

A 90ms improvement by comparing a callgraph before and after the change:

• File I/O drops from 128ms to 49ms
• Overall response drops from 246ms to 154ms
• file_get_contents duration improves by 90ms

A nice gain, considering it runs on every request in the development environment!

While working on the migration from Vagrant to Docker with Compose in our development setup, we were seeing extremely slow responses in the browser and I immediately made a mistake to assume I know the problem without measuring.

A story in 7 acts.

1. Making the wrong assumptions

From common experience, the first thing to blame was Docker Volume Performance. So I optimized the obvious issues, that you can find in the many Docker on Mac Performance blog posts around the web:

• Set the volume to :delegated or :cached (Edit: Turns out this is moot, but you’ll find it on the internet everywhere)
• Do not share the Composer and NPM/Yarn dependency folders into the container
• Enable the new experimental VirtioFS filesystem in Docker Desktop for Mac
• Regenerate the Symfony cache via docker-compose exec to make sure the cache generation is not holding up the request.

2. Reality breaks assumptions: Why is cache generation quick?

At that point I had a realization:

Using „docker-compose exec app php /app/bin/console cache:clear“ generated the cache in 3-4 seconds. If volume performance was the problem, then this CLI script should also be slow. Yet 3-4 seconds is pretty quick for generating the cache of our large Symfony application.

So it is most likely not be Docker volumes that are slow, but something in the Nginx, PHP-FPM or our application stack.

3. Identify where slowness comes from

To identify where to dig next, I executed the front controller „index.php“ script from the CLI as well.

$ docker-compose exec app php /app/web/index.php

This gave a long 60 second response, which leads me to conclude that our PHP application is slow and not Nginx or PHP-FPM. I call this divide and conquer debugging, splitting up the potential causes and eliminating them one by one.

4. Identify what causes the slowness

I installed the tideways CLI into the Docker container next and re-ran the index.php script from the CLI with:

docker-compose exec app tideways run php /app/web/index.php

Clicking on the output response to find out where the 60 seconds are coming from: Our own code making a HTTP request to a host that is not available using file_get_contents:

This is only a debug call, so its using file_get_contents and its default timeout of 60 seconds is what is causing the problem.

5. Setting Timeouts on HTTP calls

A case of not following our own advice of always setting timeouts on HTTP calls. We have a blog post on „Using HTTP Client Timeouts in PHP“ and Tideways itself warns when the default socket timeout is not adjusted to a lower value through an observation.

So changing the code to use a timeout:

private function queryMailcatchMails() : array
{
    $context = stream_context_create([
        'http' => ['timeout' => 1.0, 'ignore_errors' => true],
    ]);
    $data = @file_get_contents("http://mailcatcher.local:1025/api/messages", false, $context);

    // ...
}

Still the same slow response! Turns out, since mailcatcher.local is a domain that does not resolve with DNS, PHP is hanging in dns resolving, which for some reason is not affected by the stream timeout settings!

6. Rewriting with Symfony HttpClient

So I did a rewrite with Symfony HTTP Cilent for the code, since we use that in many other places of the code base already:

That did not work either, because of a bug in Symfony HttpClient only seting CURLOPT_TIMEOUT but not CURLOPT_CONNECTIONTIMEOUT. We still have 20 seconds spent in HTTP requests.

I have filed a bug report and will spend some time proposing a PR in the next few weeks.

7. Fixing the underlying problem: New hostname

This journey started with the migration from Vagrant to Docker, the mailcatcher.local domain was used in Vagrant, but it did not exist in Docker (yet). Once the mailcatcher service was running in the Docker Compose setup and the code changed to talk to the right HTTP host everything was fast again.

Here you can see the comparison of the old vs the new code in a callgraph comparison in Tideways: curl_multi_exec is now 19 seconds or 95% faster than before.

The moral of the story: don’t make assumptions without measuring, otherwise you might spend a lot of time optimizing something that is not slow.

In our case the Docker volumes were quick and response anyways, the problem was in the application and specifically the unavailable HTTP host.

Deprecating old code and replacing it with new and improved APIs is an established process in software development. In the core of PHP APIs are provided to trigger and to get notified of deprecations.

1. If a feature in PHP is deprecated, the language triggers a notification message with the E_DEPRECATED level.
2. As a developer, library or framework author, deprecations can be triggered directly from PHP code using the function trigger_error() with the E_DEPRECATED or E_USER_DEPRECATED levels.

As a PHP application developer you can then hook into all triggered deprecations using a user defined error handler. You can use this API to collect deprecations and fix them.

A Refactoring Workflow using Deprecations

A common workflow to slowly and safely improve your code, without potentially breaking usages of your old code is a strategy of introducing new APIs and deprecating the old ones. Both APIs are then maintained until all usages of the old API is replaced with the new API.

A checklist of this workflow looks as follows:

1. Introduce a new API that improves upon the old API.
2. Add a call to trigger_error in the old API (unless its called by the new API)
3. Roll out this change to production and start logging the deprecations with Tideways.
4. Replace ocurring deprecations where you haven’t replaced the old with the new API
5. Remove the old API as soon as you are confident the old API is not used anymore, potentially by not seeing the deprecation message anymore for several days.

If you can replace the old API with the new one in a single step, then you don’t need the indirection through using deprecations. But when an API is used wide spread throughout the code base this approach allows you to do a gradual migration instead of a big bang refactoring that introduces the risk of bugs.

Example: Deprecating an API

Lets see an example. We have a method that allows querying from a database table using many parameters to influence the query conditions, the example is directly taken from Tideways own code-basis:

<?php

interface TracepointRuleRepository
{
    /**
     * @return array<TracepointRule>
     */
    public function findAllTracepointRules(
        int $applicationId,
        bool $activeOnly = false,
        string $service = '',
        string $environment = '') : array;
}

We have recently added two new parameters to this API for $service and $environment. Because many optional parameters are a code smell, we decided to refactor this code to what we call the “Criteria API Pattern” in our team. More generally the pattern is called Parameter Object.

First we introduce the Criteria object:

<?php

class TracepointCriteria extends Struct
{
    public bool $activeOnly = false;
    public string $service = '';
    public string $environment = '';
}

Then we introduce a new method on the interface and the coresponding implementation:

<?php

interface TracepointRuleRepository
{
    /**
     * @return array<TracepointRule>
     */
    public function findMatching(int $applicationId, TracepointCriteria $criteria) : array;
}

The important part is not to change the original old API and keep it around. Instead we modify this code to trigger a deprecation:

<?php

class TracepointRuleOrmRepository implements TracepointRuleRepository
{
    /**
     * @return array<TracepointRule>
     */
    public function findAllTracepointRules(
        int $applicationId,
        bool $activeOnly = false,
        string $service = '',
        string $environment = '') : array
    {
        @trigger_error("findAllTracepointRules() is deprecated, use findByCriteria() instead.", E_USER_DEPRECATED);

        // original implementation
    }
}

After enabling deprecations tracking in Tideways, these deprecations now look like in the following screenshot:

You can see the stacktrace to this deprecation and if you start fixing occurrences, until the deprecation is not triggered again.

For the new implementation of the findMatching method there are now three approaches we can take:

1. Completly implement the new method from scratch and keep the old method.
2. Implement the new method from scratch, but call the newly implement method from the old, deprecated method.
3. Call the deprecated code from the new method. This is the most tricky, because we have to avoid that the deprecation is being triggered. We can do this by passing a parameter that controls the behavior.

<?php

class TracepointRuleOrmRepository implements TracepointRuleRepository
{
    /**
     * @return array<TracepointRule>
     */
    public function findAllTracepointRules(
        int $applicationId,
        bool $activeOnly = false,
        string $service = '',
        string $environment = '',
        bool $triggerDeprecation = true) : array
    {
        if ($triggerDeprecation) {
            @trigger_error("findAllTracepointRules() is deprecated, use findByCriteria() instead.", E_USER_DEPRECATED);
        }

        // original implementation
    }

    public function findMatching(int $applicationId, TracepointCriteria $criteria) : array
    {
        return $this->findAllTracepointRules(
            $applicationId,
            $criteria->activeOnly,
            $criteria->service,
            $criteria->environment,
            false
        );
    }
}

During Shopware Community Unconference 2022, we heard a lot about an internal performance week at Shopware, where they took tie to optimize different parts of the core of the Shopware platform. These were mostly performance problems that also affect our customers. Naturally, we are super excited about them their release in version 6.4.11. In this blog post we will look at one improvement to category navigation loading.

Comparing two Callgraphs of NavigationLoader

If you have a category-heavy Shopware 6 store, fetching and rendering the navigation menu would be a slow operation, we have seen from 100-500ms depending on the number of categories for different customers. Even smaller category trees required a disproportionate amount of time to render. We verified this with a demo shop, which the following numbers are taken from.

Comparing the performance of the NavigationLoader::loadTree function before and after the update to 6.4.11 shows roughly 15% performance gain for a store with 3097 categories (generated by the framework:demodata command).

We can see the gain by searching for all calls to the NavigationLoader class in the callgraph table view.

The whole tree fetching takes 163ms in the old code and just 14ms in the new code. What was changed?

Reducing Loop Complexity to Improve Performance

The commit to fix this performance bottleneck is not straightforward by glancing at it, but with a bit of time we can see that instead of an O(N^2) loop through all categories to build the navigation tree, it is now iterated only O(2N) times. See the Big O Notation for complexity of an algorithm if you are unfamiliar with this notation.

A quadratic complexity means that for each category all categories are iterated once again. For 2 categories we have 4 iterations, for 1,000 categories we have 1,000,000 iterations. This perfectly explains why the performance gets so much slower for large numbers of categories and you can see evidence of this in the Tideways Callgraph screenshot above.

CategoryEntity::getParentId was called 277409 times more often in the old code. This is a very simple getter, but the number of calls in the old algorithm made up for 41ms of execution, 25% of the 163ms the NavigationLoader took in total.

The new algorithm only iterates over all the categories twice.

The benefit of this performance improvement cannot be understated because it is a positive effect on all uncached pages in the store: Homepage, category pages, product pages, everything.

This post tells a story of a performance mistake that is quickly made even by experienced developers: The expectation that a built-in PHP function has better performance than a better suited data structure written in PHP.

The protagonist in these stories is array_unique, a function that takes a list of values and removes duplicate entries to return a list of each value occurring only once.

Take these two code examples, the first from Shopware 6.3:

$this->tags = array_unique(array_merge($this->tags, array_values($tags)));

The second one from our own Tideways backend code:

$versions[$row['version']]['organizations'][] = $row['organization_id'];
$versions[$row['version']]['unique'] = count(array_unique(
    $versions[$row['version']]['organizations']
));

On a first glance these snippets look innocent: append new values to an array and then make sure they aren’t duplicates of previously known values by applying array_unique.

With the help of Tideways Profiler, we found both are executed in loops and perform the unique operation many thousands of times.

The algorithmic complexity of array_unique was improved in PHP 7.2, but it is still “just” O(n), meaning for larger arrays the operation can take a while. Here is the code of array_unique translated to how it would look like in PHP:

function array_unique(array $values) {
    $seen = [];
    $uniqueValues = [];
    
    foreach ($values as $value) {
        if (!isset($seen[$value])) {
            $uniqueValues[] = $value;
            $seen[$value] = true;
        }
    }
    
    return $uniqueValues;
}

This is an efficient enough algorithm, but only if you don’t repeatedly do the operation over and over again. There are two solutions to this performance problem:

• Calculate array_unique only once at the end of the loop, while appending duplicates to the array during the loop. This strategy is simple, but might cause memory problems if the array is very large or the elements are long strings.
• Incrementally calculate uniqueness by keeping the array of $seen values around over all merges of new elements.

The second solution is easy to implement with PHP Arrays by storing the values as keys and not appending them as values. Technically this means using the $seen array from the code example as data structure:

Both code examples from the beginning of the post can be rewritten by storing the values as array keys:

foreach ($tags as $tag) {
     $this->tags[$tag] = true;
}

The list of unique tags is then fetched using array_keys($this->tags) later. We found that this change was already made from Shopware 6.3 to 6.4 in the following commit.
We rewrote our own Tideways backend code to make use of the same approach, using array keys:

$versions[$row['version']]['organizations'][$row['organization_id']] = true;
$versions[$row['version']]['unique'] = count(
    $versions[$row['version']]['organizations']
);

This benefits from using the O(1) complexity of adding an element to an array (hashmap) and array_unique is not needed anymore.

Looking at a comparison of both optimizations in Tideways Callgraph Profiler shows how massive the gains are for these changes.

In Shopware 6.3, we replaced the old CacheTagCollection code with the code from 6.4 and the performance improved from 7,3 minutes to 51 seconds for the Product Export, an improvement of 88% of which 4,08 minutes (54%) can be attributed to the removal of array_unique and another 40 seconds to the use of array_merge in the same line. Conclusion: Upgrade to Shopware 6.4!

In the case of Tidways own backend code, removing array_unique reduces 925ms from the original request that takes 1,87 seconds, a rough 50% improvement.

And here is the moral of our story: array_unique should generally be called for any array only once, not over and over again.

Intrigued by PHP performance story-telling? We are currently looking for a Developer Advocate to write about bottlenecks just like this.