The 2026 Drupal Business Survey is open. Your response will help shape the future of the Drupal business ecosystem.Problem/Motivation
Noticed this when profiling a request that loads a very large number of entities (about 10k) when caches are cold. On that page I was seeing tens of thousands of calls to array_diff/array_keys via the redis cache backend which uses this trait.
Steps to reproduce
Proposed resolution
Remaining tasks
User interface changes
Introduced terminology
API changes
Data model changes
Release notes snippet
| Comment | File | Size | Author |
|---|---|---|---|
| #3 | Screenshot 2026-03-18 at 21.35.04.png | 379.44 KB | catch |
| #3 | Screenshot 2026-03-18 at 21.32.56.png | 364.82 KB | catch |
Issue fork drupal-3580109
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
changes
Comments
Comment #3
catchNot entirely like for like screenshots, had another patch applied, but you get the idea.
Comment #4
berdirMakes sense. Reminds me of that memory cache tag issue where you saw very different profiling results with those array functions, but I suppose it's pretty clear that this is better.
Comment #5
catchThere will be some xhprof overhead and other things going on, but since we often only have a single cache tag (like
entity_field_infoon some cache items, a lot of times it's going to be a very small foreach loop.The cache items with lots of cache tags tends to be page cache / dynamic page cache where you only have one or two on a page, so even if that's faster with the array_diff() (don't think we need to check that), it's not the common case.
I can't remember the memory cache tag issue profiling results at this point, if you remember the issue I wouldn't mind checking I'm not actually contradicting myself...
Comment #6
berdirI was thinking of #3559249: Skip cache tag invalidation if no cache items have cache tags in the memory backend and #3559030: Installing from existing config causes massive cache.config population and slow installs, but that didn't seem to include the discussion/differences I remembered, maybe that was a different channel or a different issue.
It's just that while both saw an issue/improvement, it was a much bigger difference for you in your xhprof runs.
I did confirm this a bit with https://3v4l.org/ and it's performance report as well, although I had to go to 100k array items to see a significant memory difference but I also did only one call. https://github.com/sharkdp/hyperfine might be a way to do more reliable comparison. I think it's not really necessary.
Comment #7
catchAhh OK if it's different levels of improvement, and not improvement in different directions, that seems fine yeah, especially given we could be testing things with different sized arrays etc., thanks for confirming, I was slightly paranoid ;)
Comment #8
alexpottI'm guessing this performs much better as $this->tagCache grows and $query_tags is relatively small.
Committed and pushed ba4dc7c4d18 to main and c62f2f846de to 11.x. Thanks!