Build store configuration report in one array_merge call (#41098)

[lbajsarowicz]

Fixed Issues (if relevant)

1. Relates to array_merge() accumulators in loops make cache tag cleaning, flat indexing and Analytics collection quadratic #41098 — scope analysis and measurements for the whole pattern.
   That issue covers three modules, so this pull request is one of three and does not close it on its own.

Description (*)

Analytics\Model\StoreConfigurationProvider::getReport() collects 39 configuration values (as
declared in Analytics/etc/di.xml) for the default scope, then for every website, then for
every store view. Each scope was prepended to the report accumulated so far:

foreach ($this->storeManager->getStores() as $store) {
    $configReport = array_merge(
        $this->generateReportForScope(ScopeInterface::SCOPE_STORES, $store->getId()),
        $configReport                      // copies every row collected so far
    );
}

array_merge() allocates a new array and copies both operands, so each website and each store
view copies the whole report built up to that point. The work grows with the square of the
number of scopes while the report grows linearly — the merchants who feel it are exactly the
ones with many store views.

The two loops now collect the per-scope reports and merge them once:

$configReport = array_merge(...array_reverse($reportsPerScope));

The list is reversed before merging, which reproduces the previous prepend order exactly —
store views first (last store view first), then websites, then the default scope. I verified
the two variants produce identical arrays for the shapes in the benchmark below, not just the
same row count.

Measured effect

Merge cost only (config reads excluded, so this isolates what the change touches), 39 config
paths, PHP 8.5, median of 5 runs:

store views	report rows	accumulating merge	single merge
50	1 989	0.19 ms	0.009 ms
200	7 839	3.06 ms	0.037 ms
500	19 539	18.87 ms	0.092 ms
1 000	39 039	77.38 ms	0.245 ms

Websites are counted separately, so an installation pays this for websites and store views
both.

Related

Magento2.Performance.ForeachArrayMerge is meant to catch this shape, but it warns on every
array_merge inside a for/foreach body — including calls that copy a constant amount of
data — and never inspects while/do bodies. 2.4-develop carries 77
phpcs:ignore Magento2.Performance.ForeachArrayMerge annotations as a result, the two removed
here among them.

magento/magento-coding-standard#503 narrows the sniff to the accumulating shape and adds
while/do coverage (126 raw detections in 2.4-develop → 74, plus one new true finding).
Reviewing and merging it would make the remaining suppressions meaningful again — input from
the core team there is very welcome.

Manual testing scenarios (*)

1. On an installation with several websites and store views, enable Advanced Reporting
   (Stores > Configuration > General > Advanced Reporting).
2. Run bin/magento analytics:collect-data (or wait for the analytics_collect_data cron) and
   inspect the generated store_config.csv in the archive: same rows, same order as before the
   change — store view rows first, then website rows, then the default scope.
3. vendor/bin/phpunit -c dev/tests/unit/phpunit.xml.dist app/code/Magento/Analytics/Test/Unit/
   — 175 tests green, including StoreConfigurationProviderTest.

Contribution checklist (*)

• Pull request has a meaningful description of its purpose
• All commits are accompanied by meaningful commit messages
• All automated tests passed successfully (all builds are green)

[lbajsarowicz]

@magento run all tests

[m2-assistant]

Hi @lbajsarowicz. Thank you for your contribution!
Here are some useful tips on how you can test your changes using Magento test environment.
❗ Automated tests can be triggered manually with an appropriate comment:

• @magento run all tests - run or re-run all required tests against the PR changes
• @magento run <test-build(s)> - run or re-run specific test build(s)
  For example: @magento run Unit Tests

<test-build(s)> is a comma-separated list of build names.

Allowed build names are:

1. Database Compare
2. Functional Tests CE
3. Functional Tests EE
4. Functional Tests B2B
5. Integration Tests
6. Magento Health Index
7. Sample Data Tests CE
8. Sample Data Tests EE
9. Sample Data Tests B2B
10. Static Tests
11. Unit Tests
12. WebAPI Tests
13. Semantic Version Checker

You can find more information about the builds here
ℹ️ Run only required test builds during development. Run all test builds before sending your pull request for review.

---

For more details, review the Code Contributions documentation.
Join Magento Community Engineering Slack and ask your questions in #github channel.