06.
The Container Dumper
Keep on Learning!
If you liked what you've learned so far, dive in! Subscribe to get access to this tutorial plus video, code and script downloads.
If you liked what you've learned so far, dive in! Subscribe to get access to this tutorial plus video, code and script downloads.
Whoops, an error! Please, try again later.
6 Comments
If to compare var_export ($container) before
$container->compile();
and var_export ($container) after that ,
we see a big difference. Last one became more puffy.
What technically is the sense of ->compile() ?
Is this step must be made just to prepare $container for consuming by new PhpDumper() and further dumping?
From the other hand, look, if to comment this line out:
$loader->load('services.yml');
//$container->compile();
$dumper = new PhpDumper($container);
file_put_contents(__DIR__.'/cached_container.php', $dumper->dump());
runApp($container);
and then commit in bash: php dino_container/roar.php
we get all the same nice cached_container.php file , but even quicker (24 ms versus 38ms).
Could you clarify all this for me?
Hi Andrew!
Wow, this is really interesting what you've done! The compile() step runs the "compiler pass" process (https://knpuniversity.com/s... - a series of functions that make final changes to the container before it's dumped. So, as you saw, you can dump it before, but you're skipping these compiler pass functions.
What do they do? Well, any bundle can add compiler passes, so it depends. But most *are* important. The most common thing a compiler pass does is process dependency injection tags. For example, if you created an event listener/subscriber by adding a service and tagging it with kernel.event_listener (or kernel.event_subscriber), that won't work until a compiler pass runs that processes that (it's called the RegisterListenersPass). If you want to see what other compiler passes are registered, they are added inside bundle classes - e.g. FrameworkBundle adds most of them to the system.
My guess is that the faster response is due to the fact that these "extra" things aren't hooked up. But, you need them :). Probably, in a large application, the difference between a compiled and non-compiled container would *still* be quite small - like the 14ms you're seeing. So, if your app takes 250ms to load, you won't notice much difference.
Anyways, very interesting detective work on this! I would not have expected a performance difference (the 14ms) of this size.
Cheers!
Hi There,
I have one question here. If i add a new service to my services.yml after caching the container, how will that be loaded automatically while the container is already compiled and dumped and i have a check in my code to complie and dump the container only if there is no cached container.
Thanks in advance.
Cheers!
Hey Junaid Farooq
It depends, if you are on dev environment, then you have nothing to worry about, because Symfony is smart enough to detect that you require a fresh container, but if you are on prod environment, then, after doing a change, you will have to clear the cache, so you can see your changes reflected.
Cheers!
Thanks MolloKhan
I was thinking of clearing the cache too but didnt know about this automatic behavior of Symfony in Dev Environment.
Cheers!
I remember something about services being private by default in some changelog...
Things are good until you actually compile the container. Instead of roaring, the script screams an exception about the "logger" service or alias being removed or inlined when the container was compiled.
Setting the logger service
public: truein services.yaml fixes the issue ;)Thanks for another insight on Symfony.
"Houston: no signs of life"
Start the conversation!