-
-
Notifications
You must be signed in to change notification settings - Fork 9.6k
[RFC] Extract PropertyAccessor readProperty and writeProperty methods to allow faster ObjectNormalizer #28926
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
Labels
PropertyAccess
RFC
RFC = Request For Comments (proposals about features that you want to be discussed)
Comments
I 100% agree with this agenda. |
@nicolas-grekas any thoughts on this? |
probably related: |
7 tasks
1 task
Closing as #29999 is a better solution. |
fabpot
added a commit
that referenced
this issue
Jan 30, 2019
…(xabbuh) This PR was merged into the 4.3-dev branch. Discussion ---------- [PropertyAccess] speed up accessing object properties | Q | A | ------------- | --- | Branch? | master | Bug fix? | no | New feature? | no | BC breaks? | no | Deprecations? | no | Tests pass? | yes | Fixed tickets | #28926, #29405 | License | MIT | Doc PR | I propose to improve the performance of the `ObjectNormalizer` by not adding a new interface to the PropertyAccess component, but by adding some shortcut for cases where we know that we do not need to perform all checks. The added benefit is that this will not only speed up the `ObjectNormalizer` class, but will be available for every consumer of the `PropertyAccessor` without having to adapt to a new API. TODO: - [ ] confirm that these changes indeed introduce the same benefit as #29405 doing an actual benchmark Commits ------- ef7876e speed up accessing object properties
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
PropertyAccess
RFC
RFC = Request For Comments (proposals about features that you want to be discussed)
Background
While working on improving the
ObjectNormalizer
, I spotted that most of the execution time is spent inPropertyAccessor::getValue
(https://blackfire.io/profiles/e52b7b58-060d-448a-bcc4-015df290812a/graph).After looking at the
PropertyAccessor::getValue
, I first had the feeling that callingPropertyAccessor::readProperiesUntil
to get an attribute value was overkill.After adding a
PropertyAccessor::hack
to exposePropertyAccessor::readProperty
, I got a significant improvement ofObjectNormalizer
perfs (https://blackfire.io/profiles/compare/6e4aa9d9-c5dd-4243-89c0-c19f431b6bc9/graph).Proposal
The idea is to extract
PropertyAccessor::readProperty
to allow it's usage by theObjectNormalizer
and bypass all the array logic executed when callingPropertyAccessor::getValue
.To achieve this, I would first replace the
$zval
and$result
arrays by an internalZval
class. This will allow type safety.Then I would add two internal classes (
ObjectPropertyReader
andObjectPropertyWriter
) that will useZval
objects as input and output.Finally I would add an
ObjectPropertyAccessor
class that will exposeObjectPropertyReader::readProperty
andObjectPropertyWriter::writeProperty
to users and hideZval
stuff.The
ObjectNormalizer
will use this newObjectPropertyAccessor
instead of thePropertyAccessor
to get the perf improvement.Going further
Deprecating
PropertyNormalizer
andGetSetMethodNormalizer
Having an interface to access object properties will help us to deprecate
PropertyNormalizer
andGetSetMethodNormalizer
by extracting code used to access properties into implementations ofObjectPropertyAccessorInterface
.Extracting
getReadAccessInfo
andgetWriteAccessInfo
fromObjectPropertyAccessor
To go further in the performance improvement, we could extract the
getReadAccessInfo
andgetWriteAccessInfo
logic to an other class. Then we will be able to ship a decorator which leverage the PHP7 static array cache.Having an interface for
getReadAccessInfo
andgetWriteAccessInfo
open the path to solve issues like #9336 by introducing metadata which could also be cached to keep the performance!WDYT ?
cc @dunglas @nicolas-grekas, @Tobion and @bendavies.
The text was updated successfully, but these errors were encountered: