The views data cache is one of the most expensive caches to build, and one of the largest runtime caches to store/load in APCu. See notes and timings in #3257725-25: [PP-1] Add a cache prewarm API and use it to distribute cache rebuilds after cache clears / during stampedes → and downwards. Also see 🐛 ViewsData should not cache by language Needs work for different ideas on how to possibly optimize views data.
Many sites have over 200 field config entities, I have seen sites with over 1,000 field config entities. The more fields on a site, the worse things get.
However, many fields aren't used in views data at all, although this tends to be site-specific, but for example it's years since I've used a 'body' field in views. Or any of the fields on a block content entity for example.
Views could add a third party setting to field config entities like 'provide_views_data', default this to TRUE, but when it's FALSE, don't provide views data for that field (no field, no filter, no argument etc.)
If a site needs views data for the field after all, they can change the flag.
If the flag is enabled, you can switch it off, but we can check against config dependencies of views on the site (the same as we could if it was being deleted) and prevent this from happening when a field is being used.
This would be an extra checkbox on field settings, or maybe even a config key with no UI, but it would give us tools to reduce bloat in the views data cache.
Active
11.0 🔥
Last updated
It affects performance. It is often combined with the Needs profiling tag.