PageRegion::loadForTheme can statically regions cache per-theme

I wonder if opting into static_cache would have the same effect as done in ✨ Opt into static_cache for component config entities Active instead of this approach.

#4++ — so stated this at #3540075-4: Opt into static_cache for component config entities → .

wim leers → credited larowlan → .

Actually, my #4 was wildly wrong, and I only realized it after actually reading the MR. Sorry.

Asked concrete questions on the MR. I suppose that the real problem here is that PageRegion::loadForActiveTheme() is called many times in different places rather than being loaded once. And so I suspect that actually adding static caching to PageRegion::loadForActiveTheme() until many calls are refactored away (if ever) is the better course of action?

You know what? I just realized we have this:

  // Use memcache for bootstrap, discovery, config instead of fast chained
  // backend to properly invalidate caches on multiple webs.
  // See https://www.drupal.org/node/2754947
  $settings['cache']['bins']['bootstrap'] = 'cache.backend.memcache';
  $settings['cache']['bins']['discovery'] = 'cache.backend.memcache';
  $settings['cache']['bins']['config'] = 'cache.backend.memcache';

Which means config _should_ have gone through the chained backend. So maybe this should be a "won't fix" since we didn't have chained fast backend.

APCu would likely not be big enough to hold all Component config entities.

Can you please add static caching to only PageRegion::loadForActiveTheme() and observe the impact of that?

(I'm curious what would happen if we'd decorate core's \Drupal\Core\Config\Entity\Query\Query::loadRecords() and do in-memory caching there, but I suspect it'd make memory consumption go up massively.)

Thinking about this more, I wonder if XB should do something like entity.memory_cache for its entities; and specifically for the PageRegion (this issue) and Component config entities (not this issue, but by far the one XB needs most of).

The entity.memory_cache.slots: 1000 container parameter that was added in Drupal 11.2 ( CR → ) seems an interesting way to keep memory consumption under control (thus negating the concern I surfaced in #10), while still reducing I/O, and would make it tunable.