The new version of config_split relies heavily on the config dependency manager to calculate the configuration that should be included in a specific split. Unfortunately, this process doesn't scale well for sites with a large number of configuration entities that need to be split.
It appears there are some optimizations we can make within \Drupal\Core\Config\Entity\ConfigDependencyManager and \Drupal\Core\Config\ConfigManager to alleviate this issue.
The calls to array_multisort within ConfigDependencyManager::getDependentEntities account for a large majority of this time (~65%).
$sorts = $this->prepareMultisort($graph, ['weight', 'name']);
array_multisort($sorts['weight'], SORT_DESC, SORT_NUMERIC, $sorts['name'], SORT_ASC, SORT_NATURAL | SORT_FLAG_CASE, $graph);
Checking a couple of references/call stacks to this function it doesn't look like the sorting is actually needed. This sorting code is also duplicated in ConfigDependencyManager::sortAll which is called by the config system elsewhere.
Additionally, within ConfigManager::findConfigEntityDependencies we could benefit from some type of caching. In my stack trace I saw it was executed about 150 times, but it called ConfigDependencyManager::getDependentEntities 130k times. I added static caching to this section of code and saw a roughly 20% improvement in performance.
Active
11.0 🔥
Last updated
It affects performance. It is often combined with the Needs profiling tag.
A performance profile visualization showing Drupal configuration dependency system execution time. The highlighted row, "php::array_multisort" consumes 25% of execution time with 130,893 executions, suggesting a potential optimization target. The most time-consuming function is ConfigManager::findConfigEntityDependencies at 66.88% of execution time with 105 executions.