Improve performance of DataObject magic calls and addData() #36345

igorwulff · 2022-10-21T09:51:07Z

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)

Fixes magento/magento2#<issue_number>

Manual testing scenarios (*)

...
...

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)

Resolved issues:

resolves [Issue] Improve performance of DataObject magic calls and addData() #37637: 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.

m2-assistant · 2022-10-21T09:51:10Z

Hi @igorwulff. Thank you for your contribution
Here are some useful tips how you can test your changes using Magento test environment.
Add the comment under your pull request to deploy test or vanilla Magento instance:

@magento give me test instance - deploy test instance based on PR changes
@magento give me 2.4-develop instance - deploy vanilla Magento instance

❗ 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:

Database Compare
Functional Tests CE
Functional Tests EE,
Functional Tests B2B
Integration Tests
Magento Health Index
Sample Data Tests CE
Sample Data Tests EE
Sample Data Tests B2B
Static Tests
Unit Tests
WebAPI Tests
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 Magento Contributor Guide documentation.

⚠️ According to the Magento Contribution requirements, all Pull Requests must go through the Community Contributions Triage process. Community Contributions Triage is a public meeting.

🕙 You can find the schedule on the Magento Community Calendar page.

📞 The triage of Pull Requests happens in the queue order. If you want to speed up the delivery of your contribution, join the Community Contributions Triage session to discuss the appropriate ticket.

✏️ Feel free to post questions/proposals/feedback related to the Community Contributions Triage process to the corresponding Slack Channel

lib/internal/Magento/Framework/DataObject.php

…e identified

ihor-sviziev · 2022-10-21T12:24:33Z

@magento run all tests

magento-automated-testing · 2022-10-21T12:24:40Z