-
Notifications
You must be signed in to change notification settings - Fork 2.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Replace spl_object_hash() with spl_object_id() #8837
Conversation
It is more efficient, and can be provided to 7.1 users thanks to symfony/polyfill-php72.
Comparative benchmark (based on https://phpbench.readthedocs.io/en/latest/guides/regression-testing.html):
It can be easier to interpret with some color: I think the differences in standard deviation can be ignored, and I notice that the result is consistently positive, especially for To reproduce it locally, try this:
|
@@ -32,6 +32,7 @@ | |||
"doctrine/persistence": "^2.2", | |||
"psr/cache": "^1 || ^2 || ^3", | |||
"symfony/console": "^3.0 || ^4.0 || ^5.0 || ^6.0", | |||
"symfony/polyfill-php72": "^1.23", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is in order to polyfill spl_object_id
: https://github.com/symfony/polyfill-php72/blob/9a142215a36a3888e30d0a9eeea9766764e96976/Php72.php#L89-L100
This is a great idea via polyfill! |
With more revolutions and iterations:
The results are similar memory-wise, cpu-wise it's less good |
👍 , since https://github.com/php/php-src/pull/7010/files#diff-43d1339545d5d900325c0ce9a1285f63dbee8a203559fa5893128b37cdbc9c37R660 |
7.1 is the only version that will use the polyfill, and I don't expect a bigger negative benchmark impact there. It uses |
I don't know if we have a list of reasons of dropping PHP 7.1 but that would certainly add to it. In fact, it's the second time in a short timeframe that it's suggested: #8838 (comment) . Maybe we should reconsider it, but that's another story. |
@greg0ire reconsider how? Both issues are related to spl_object_id which csn be polyfilled as you showed. We should drop 7.1 with ORM 3.0 |
By compiling a list of benefits mentioned here and there, and by taking a look at the newly available Packagist stats: https://packagist.org/packages/doctrine/orm/php-stats . Maybe we should even have a policy about dropping versions of PHP based on these stats, since I don't think waiting for 4.0 to drop 7.2 is going to be reasonable. In the meantime, can either of you please approve this PR? |
At the rate we're going, we should at least aim to drop PHP 7.3. |
@@ -3241,7 +3241,7 @@ public function registerManaged($entity, array $id, array $data) | |||
* INTERNAL: | |||
* Clears the property changeset of the entity with the given OID. | |||
* | |||
* @param string $oid The entity's OID. | |||
* @param int $oid The entity's OID. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This was actually a BC break regarding gedmo/doctrine-extensions
(they adapted the code in doctrine-extensions/DoctrineExtensions#2272 though, so no need to revert it as a second BC break).
this method has INTERNAL:
in its description, but it is not tagged as @internal
so using it in third-party code is not flagged. And it looks like there is no public API allowing to achieve that goal.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, I see that #9143 actually documents it
It is more efficient, and can be provided to 7.1 users thanks to
symfony/polyfill-php72
.Backports #6878
@beberlei I know we wanted to target Doctrine 3 with this, but I found a way to target v2. WDYT?