The time to add a new field, and the time to delete a field, grows with the number of existing fields.
I've been doing some benchmarking of the entity field api to explore whether it could serve as the foundation for webform module in D8 (see Issue #2075941). This benchmarking uncovered the following behaviour in 8.0.0-beta9:
- The time to add a new field grows with the existing field count. At 1,000 existing fields, the time is ~1 second.
- The time to delete a field grows with the existing field count. At 1,000 fields, the time is ~10 seconds.
- Field management, form and display configuration, and entity render times seem unaffected.
This behaviour could pose performance problems for sites with a large number of fields, webform or no.
Steps to Reproduce
I used the attached script of custom drush commands to benchmark. (Change filename to 'entityform.drush.inc' and place in .drush folder).
// Add 100 content types. drush ebct node 100 // Add 10 fields to each content type. drush ebaf node all 10
Then add/delete a field via the UI.
I'll preface this by saying I am relatively new to D8 core, but I believe the cause has to do with certain methods defined in EntityManagerInterface that fetch field config/field storage config definitions for all bundles of a single entity type, or for all bundles of all entity types. For example, EntityManager::getFieldMap() builds a map of all field definitions across all entities. This method is executed when a field is deleted, and xhprof tells me it's very costly (~9 seconds in the above benchmarking).
I'm not sure if this is related, but from poking around in the DB I also noticed that for each entity type, there exists a serialized array of all field_storage_config entities belonging to it. In the above benchmarking (1,000 total node fields), the size of the serialized array for the node entity type was approaching 1MB in size.
A solution would involve making these methods accept entity type and bundle arguments so that field configuration is only fetched in smaller pieces at a time. Code that uses these methods would need to be refactored. I suspect this would require some refactoring of the config architecture for fields as well, but I'm not familiar enough with those internals to say for sure.
1. Validate above results.
2. If validated, isolate causes and decide whether fixes are necessary.
3. If a fix is deemed necessary, create patch(es).
User interface changes
None that I can see. This is all back-end stuff.
Changes to the EntityManager as discussed above.
Possibly changes to the config/caching system for fields.
PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 91,933 pass(es). View