Use separate config schema cache items

Created on 3 January 2014, over 11 years ago
Updated 3 June 2025, 21 days ago

Problem

  • The config schema reads (and caches) all available schema definitions at once, instead of individual schema definitions, even though the primary use-case requires schema information about a single config object only.

Details

  • There are ~70 config schema files just in core, each of them containing larger data structures.

Proposed solution

  1. Change SchemaStorage to load (and cache) individual config schemata (possibly aggregated by provider/prefix) to reduce memory consumption and improve performance.
  2. Invalidate and flush the cache when appropriate (possibly by provider/prefix).
πŸ“Œ Task
Status

Postponed: needs info

Version

11.0 πŸ”₯

Component

configuration system

Created by

πŸ‡©πŸ‡ͺGermany sun Karlsruhe

Live updates comments and jobs are added and updated live.
  • Performance

    It affects performance. It is often combined with the Needs profiling tag.

  • stale-issue-cleanup

    To track issues in the developing policy for closing stale issues, [Policy, no patch] closing older issues

Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • πŸ‡ΊπŸ‡ΈUnited States smustgrave

    Thank you for creating this issue to improve Drupal.

    We are working to decide if this task is still relevant to a currently supported version of Drupal. There hasn't been any discussion here for over 8 years which suggests that this has either been implemented or is no longer relevant. Your thoughts on this will allow a decision to be made.

    Since we need more information to move forward with this issue, the status is now Postponed (maintainer needs more info). If we don't receive additional information to help with the issue, it may be closed after three months.

    Thanks!

  • πŸ‡¨πŸ‡­Switzerland berdir Switzerland

    Checking a single config involves dynamically resolved types in many different config files (e.g. something like views or entity view displays). I think this is not practical.

Production build 0.71.5 2024