This issue is automatically created based on existing pull request: #36345: Improve performance of DataObject magic calls and addData()

The magic calls from the DataObject are being called over a 100k when there is no block_cache available and depending on the page often thousands of times when all block_cache is available.

The small change for addData() is just included because its a tiny optimization and prevents a bug from happening. When a $value is an array the original call to setData would override the internal $_data array, this is not expected behavior and just setting it directly to $_data is faster anyway.

The other change is in the __call magic method and the _underscore function and the change is quite radical. Since this method can be called so often, we want to prevent further function calls if possible. Functional calls are normally not that expensive, but will become more expensive if you use this extensively (thousands of even hundred of thousands extra calls):

These are my own benchmarks based on a local environment with opcache and with PROD mode.

HOMEPAGE transaction
All cache enabled except for FPC (__call is called 975 times): 4.318307ms -> 1.469747ms All cache enabled except for FPC + Block_html (__call is called 100379 times): 385.36412ms -> 88.412914ms

PLP transaction:
All cache enabled except for FPC (__call is called 4628 times): 19.625463ms -> 5.754514ms All cache enabled except for FPC + Block_html (__call is called 112591 times): 404.84066ms -> 99.390374ms

Now this PR also skips some checks. It assumes if a $method call start with 'g' it will be for 'get' for example, this is done in my PR to get the most optimal performance result but might not be preferred. I also removed an index check with $args[1] for the setter since it isn't used anywhere, but might also be something we would want to change.

Description (*)

Related Pull Requests

Fixed Issues (if relevant)

1. Fixes magento/magento2#<issue_number>

Manual testing scenarios (*)

1. ...
2. ...

Questions or comments

Contribution checklist (*)

• Pull request has a meaningful description of its purpose
• All commits are accompanied by meaningful commit messages
• All new or changed code is covered with unit/integration tests (if applicable)
• README.md files for modified modules are updated and included in the pull request if any README.md predefined sections require an update
• All automated tests passed successfully (all builds are green)