Problem/Motivation
With #3442009: OOP hooks using attributes and event dispatcher and #3396165: [meta] Convert all core plugin types to attribute discovery (and potentially others in the future like autowiring) we're going to be doing a lot of scanning for attributes in core.
In general, each thing-that-looks-for-attributes implements iterating over a load of files, getting the attributes via reflection, then pulling out whatever information it needs, either into the symfony container or into a cache entry.
We won't have reliable profiling numbers on this until lots of conversions are done and possibly not until someone profiles a 150+ module site in the wild, but it's likely to be expensive.
Steps to reproduce
Proposed resolution
I think we can possibly use filecache to mitigate most or all performance overhead from scanning attributes.
In this issue, we're just adding FileCache around hook discovery, possibly later on we could try to make it generic:
We can implement something that:
- given a file
- collects all the attributes from that file at once
- puts them into a structure that we can store in filecache (which is based on the mtime of the file so persists across cache clears)
- allows a single attribute value to be returned from a method, possibly all of them.
If we use this in all/most of the places we are parsing attributes, then files that potentially use more than one type of attribute (like a service that provides a route using route attributes, whenever that lands, as well as a hook implementation), would only be parsed once instead of for each service that needs to check.
This should be easy when Drupal is doing the attribute parsing, it may be more complicated for the container itself, but maybe we can swap that out too.
I don't yet know what the API or data structure might look like, only have the very rough outline above so far.