Generated with the help of an LLM.
The problem was demonstrated to me, and profiled with the help of a coding agent. These words are my own. The MR was mostly written by the agent.
Problem/Motivation
Every time a field config, field storage or base field override is saved or deleted we clear all DataType plugin definitions, both static and persistent, so the derivers for entity:* and field_item:* have to run again. Data type definitions depend on entity types, bundles and field type plugins, not on field instances, so there's no reason to clear them here.
This happens in EntityFieldManager::clearCachedFieldDefinitions(), which calls TypedDataManager::clearCachedDefinitions() to reset the cached property prototypes. That also wipes the definitions.
This came up before in #2114707-33: Allow per-bundle overrides of field definitions where @berdir said that clearCachedDefinitions() "clears way more than we're interested in". #2487287: Optimize/clean up cache clears when saving/deleting FieldConfig entities is about cleaning up the other cache clears on field config save and delete.
Steps to reproduce
- Install a site from existing config with lots of field configs, or create fields in a loop
- Count calls to
EntityDeriver::getDerivativeDefinitions(), it runs again after every field save
Proposed resolution
- Add
TypedDataManagerInterface::clearCachedPrototypes()that only clears the static prototypes - Call that from
EntityFieldManager::clearCachedFieldDefinitions()instead ofclearCachedDefinitions()
Note this is an interface change so BC could be tricky.
Remaining tasks
User interface changes
Introduced terminology
API changes
Data model changes
Release notes snippet
Issue fork drupal-3633372
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #3
mstrelan commentedI filed this as a bug but I guess it could also be considered a task.
With the change in the MR:
drush site:install demo_umami:EntityDeriver::getDerivativeDefinitions()is called 75 times instead of 148. The time difference is negligible since Umami only has 38 field configs.drush site:installdrops from ~54.0s to ~50.5s, about 6.5%.