This loads each item one by one, with the database storage that can be hundreds/thousands of queries.
We can load all at once or chunk instead. Saves 200+ms from drush cim -y.
Multiple load the config items in chunks of 500. Sites tend to have between 1500-4000 config objects so this will result in the loading happening in 3-8 queries.
| Comment | File | Size | Author |
|---|---|---|---|
| #2 | Screenshot from 2026-07-12 20-23-10.png | 447.7 KB | catch |
| #2 | Screenshot from 2026-07-12 20-14-28.png | 449.58 KB | catch |
Show commandsStart 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 #2
catchSaves a couple of hundred milliseconds on a drush cim -y call with Umami, will be more with more config on a site.
Goes with #3591680: Use the YAML parsing cache collector for config file storage for the file parsing.
Comment #4
catchComment #5
smustgrave commentedSorry could we update the issue summary with the proposed change. How did you determine 500?
fwiw I like the idea of chunks after that fun bug with the entity field queries and 60+ fields so +1 to chunking it!
Comment #6
catchUpdated the issue summary.
500 is a bit arbitrary. Most sites have 1500-4000 config objects from what I've seen, so this means 3-8 database queries. Wouldn't want to go over 500, but we could go down to 200 and it would still be 1/200th the database queries. Don't think it's worth making configurable.
Comment #7
smustgrave commentedThanks for humoring me. Think the change makes sense. Lets give it a shot.
Comment #8
godotislate1 Q on the MR.
Comment #9
godotislateComment #10
catchReplied on the MR - the memory storage is only used in tests, and that method never actually got called before. Now that it gets called, it fails.
Comment #11
catchI pushed a commit to revert that change and then a second commit to fix the one-liner itself. For me I prefer the foreach than the array acrobatics but it makes it a bit more obvious how the current logic is broken. If we want to go back to the foreach, it'd be reverting the last two commits on the MR.
Comment #12
godotislateI don't mind the
foreach, and thanks for explaining the change.Actually, if we're doing the foreach, we can simplify. Adding an MR suggestion.
Comment #13
godotislateComment #14
catchYes that's even better! Applied the suggestion.
Comment #17
godotislateCommitted and pushed bad194b to main and 7230379 to 11.x. Thanks!
Comment #19
catchTentatively tagging for 11.5.0 release highlights.
In combination with #3591680: Use the YAML parsing cache collector for config file storage this cuts more than half the time off a drush config import.
A lot of the remaining time in drush config import is in building a dependency container, but I think the
config import (that doesn't do much actual config changes or is a no-op) should be a couple of hundred milliseconds vs. 2-3 seconds or more with 11.4 and drush. I'm adding up the individual pieces here, haven't actually done a side by side comparison and not even sure
drhas a config import command yet.