Feature: #57594 - Optimize ReflectionService Cache handling¶
See Issue #57594
Since its beginnings, Extbase came along with two main caches for reflection data,
extbase_object. The latter mostly stored information that were relevant
to the dependency injection, like inject methods, inject properties and constructor parameters. The
information was gathered by actual reflection and by analysing doc blocks of properties and methods.
extbase_reflection stored similar reflection and doc block data about objects but mainly for the
parts outside dependency injection.
For example, the validation resolver used it to identify
@validate tags, the ActionController used
it to identity which properties not to validate. The ORM also used it a lot to find annotated types
There were a few issues with these two approaches:
- A lot of redundant data was fetched
- Data was fetched multiple times at different locations
extbase_reflectioncache was stored each plugin separately, resulting in a lot of redundant cache data for each plugin cache
- At a lot of places, the reflection service was used to reflect objects, but the data wasn’t cached or taken from a cache resulting in performance drawbacks
extbase_objectcache has been removed completely and all necessary information about objects, mainly
@injectfunctionality, is now fetched from the
ReflectionServicedoes still create
ClassSchemainstances but these were improved a lot. All necessary information is now gathered during the instantiation of ClassSchema instances. This means that all necessary data is fetched once and then it can be used everywhere making any further reflection superfluous.
- As runtime reflection has been removed completely, along with it several reflection classes, that analyzed doc blocks, have been removed as well. These are no longer necessary.
extbase_reflectioncache is no longer plugin based and will no longer be stored in the database in the first place. Serialized
ClassSchemainstances will be stored in
var/cache/for composer-based installations.