@@ -186,3 +186,44 @@ your application::
186186 }
187187 }
188188
189+ This could be further improved by only recompiling the container in debug
190+ mode when changes have been made to its configuration rather than on every
191+ request. This can be done by caching the resource files used to configure
192+ the container in the way describe in ":doc: `/components/conf/caching `"
193+ in the config component documentation.
194+
195+ You do not need to work out which files to cache as the container builder
196+ keeps track of all the resources used to configure it, not just the configuration
197+ files but the extension classes and compiler passes as well. This means that
198+ any changes to any of these files will invalidate the cache and trigger the
199+ container being rebuilt. You just need to ask the container for these resources
200+ and use them as metadata for the cache::
201+
202+ // ...
203+
204+ // set $isDebug based on something in your project
205+
206+ $file = __DIR__ .'/cache/container.php';
207+ $containerConfigCache = new ConfigCache($file, $isDebug);
208+
209+ if ($cache->isFresh()) {
210+ require_once $file;
211+ $container = new MyCachedContainer();
212+ } else {
213+ $container = new ContainerBuilder();
214+ //--
215+ $container->compile();
216+
217+ $dumper = new PhpDumper($container);
218+ $containerConfigCache->write(
219+ $dumper->dump(array('class' => 'MyCachedContainer')),
220+ $container->getResources()
221+ );
222+ }
223+
224+ Now the cache is used regardless of whether debug mode is on or not. The difference
225+ is that the ``ConfigCache `` is set to debug mode with its second constructor
226+ argument. When the cache is not in debug mode the cached container will always
227+ be used if it exists. In debug mode, an additional metadata file is written with
228+ the timestamps of all the resource files. These are then checked to see if the files
229+ have changed, if they have the cache will be considered stale.
0 commit comments