Problem/Motivation

With #3506930: Separate hooks from events, hook data is now stored in keyvalue and (again) loaded from cache, as one single cache item.

There might be potential for more optimized caching, but it's challenging for a number of reasons, so I think we need to be very carefully weigh pros and cons and figure out if and how that should be done.

Thoughts I had:
* The hook structure is pretty small now, there's not a ton of savings to be had. Compared with entity and field definitions other plugin definitions like blocks (which all can be massive), it's probably minor and might be worth our time more to try and optimize that.
* First hooks are pretty early in bootstrap, especially on multilingual sites. Lots of interdependencies. We could maybe check session vs no session, but for authentication providers that load the user entity, that also triggers hooks. Admin route vs not is way too late.
* Cache invalidation: If we have an unknown set of cache items, we need more complex invalidation, such as cache tags. This would cause some issues with redis, similar to #3550684: Allow cache delete operations during container rebuild but possibly harder to work around as the usage is in the core trait
* On cold caches, a considerable amount of hooks are invoked, also for anonymous users.
* Maybe a cache collector to skip completely unused hooks, such as hook when the module isn't installed. But: In the past when we slowly built up our knowledge of caches, so had many update writes, that's no longer a concern now, we just write it once and are done. That's a considerable advantage.
* One vague idea I had is a two-stage cache, one cache item for dynamic page cache hits and then another if we're passed that. But that also increases our external dependencies, we need events to switch stages and so on.

In summary, I currently rather doubt that a further split is worth it for the vast majority of sites.

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

Comments

berdir created an issue. See original summary.

berdir’s picture

berdir’s picture

One different idea was to write the cache directly instead of only deleting it, we need to make sure that doesn't hit any weird edge cases:

> I thought about that, but I was concerned about a recent slack discussion with @mglaman on edge cases such as update cache overrides, that disable write/read and just keep delete.

Version: 11.x-dev » main

Drupal core is now using the main branch as the primary development branch. New developments and disruptive changes should now be targeted to the main branch.

Read more in the announcement.

nicxvan’s picture

Do we still think this is worth exploring?

nicxvan’s picture

Status: Active » Postponed (maintainer needs more info)