#1187726-118: Add caching for configuration / rework config object loading (Was: Memory usage and i/o from config objects) introduced the concept of persisting services across kernel reboots, and made the config factory one such service. However, I don't understand why that was needed. Was it for functional reasons? Performance reasons? If performance, for what scenario? Cause kernel reboots are very infrequent operations on a production site.
Starting with a quick patch to see if bot identifies a functional reason.
| Comment | File | Size | Author |
|---|---|---|---|
| #2 | service_persist.2.patch | 1.64 KB | effulgentsia |
| service_persist.patch | 615 bytes | effulgentsia |
Comments
Comment #2
effulgentsia commentedThose test failures are easily fixed. What else?
Comment #4
effulgentsia commented#2: service_persist.2.patch queued for re-testing.
Comment #5
chx commentedThe recent config import switch to config->save() probably deprecated that facility yes. Let's remove it!
Comment #6
effulgentsia commentedThanks, chx. What's "needs work" then? I still like the ability to persist services, and we need to do so for synthetic services as part of #1872522: Compiled data in PHP storage is cleared too late in drupal_flush_all_caches(), and maybe down the road will want to do it for non-synthetics like 'database', so I also like the tag. I think all that's needed in this issue is to just not use it for config.factory, which is all #2 does. So, perhaps RTBC? Retitling issue as well.
Comment #7
chx commentedAh so you don't want the facility to be removed ? fine by me *however* I still leave at NW or it could be postponed perhaps because it conflicts with #1331486: Move module_invoke_*() and friends to an Extensions class. When that goes in, hopefully soon, this can follow.
Comment #8
effulgentsia commentedOk. In that case, I merged it into #1878512-8: Clean up Simpletest's kernel/container preparation/rebuild logic now that the kernel is responsive to module enabling which is what I was wanting it for anyway.