Use multiple get for #pre_render / #cache where possible

Created on 17 March 2015, about 10 years ago
Updated 21 March 2025, about 1 month ago

Problem/Motivation

#pre_render + #cache is great, but has one big disadvantage:

Items in listings (300 comments, 20 blocks) are gotten one item at a time.

That means 300 cache_get instead of one cache_get_multiple().

The previous block cache did a get_multiple per region and hence was faster.

Proposed resolution

Add a cache pre-fetching foreach () loop on all children to Renderer::render().

Possibly set the pre-warmed data on an internal #cache_data attribute temporarily and remove after the #cache check again.

Remaining tasks

- Write a patch

User interface changes

- None

API changes

- None, no API change at all. Pure performance optimization.

--

This is major because of the performance impact. It likely is also a pretty simple quick fix.

📌 Task
Status

Active

Version

11.0 🔥

Component

cache system

Created by

🇩🇪Germany Fabianx

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

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

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 Kingdom catch

    Render cache multiple get is now in core after 📌 Render the navigation toolbar in a placeholder Active , we should see if there's an example in core where this would help, and then try to implement it in the renderer.

  • 🇨🇭Switzerland berdir Switzerland

    The combination of those 4 issues means we now have efficient get multiple cache loading for placeholdered routes and we have quite a few of those now with menus, block_content, local tasks and so on being placeholdered:

    📌 Render the navigation toolbar in a placeholder Active
    Optimize placeholder retrieval from cache Active
    Optimize redirect chain retrieval in VariationCache Active
    📌 Create placeholders for more things Active

    So I think the benefits for blocks aren't that huge, you'd need multiple non-placeholdered blocks in the same region for this to be efficient. We might want to instead look into either placeholder even more blocks or then not cache them on their own at all # 📌 Add CacheOptionalInterface to more blocks Needs review ).

    Looking at umami, the only blocks that are not placeholdered are: umami_search (simple form, pretty fast to build), umami_branding (also pretty simple), umami_messages (just puts in a placeholder, definitely could be non-cacheable?) and umami_help (unsure, but depends on route, so high amount of variations). So, not a lot of benefit here.

    But I think one scenario where this is still interesting is what I mentioned #6. If you have a view with 50 nodes that gets invalidated, then you can fetch them with a single cache get instead of 50 (with cache redirects, possibly even 2 instead of 100). To measure the benefit, we'd need to create a handful of articles for the frontpage view.

    We'd need to run the children through getMultiple() and somehow flag those that have been fetched, so we don't attempt to load them again.

Production build 0.71.5 2024