This tutorial has a new version, check it out!
> Symfony 4 > Doctrine & the Database in Symfony 4
Login to bookmark this video
Buy Access to Course
08.

Service Subscriber: Lazy Performance

Share this awesome video!

|

Keep on Learning!

Start your All-Access Pass

With a Subscription, click any sentence in the script to jump to that part of the video!

Login Subscribe

Our nice little Twig extension has a not-so-nice problem! And... it's subtle.

Normally, if you have a service like MarkdownHelper:

31 lines | src/Twig/AppExtension.php
// ... lines 1 - 4
use App\Service\MarkdownHelper;
// ... lines 6 - 9
class AppExtension extends AbstractExtension
{
private $markdownHelper;
public function __construct(MarkdownHelper $markdownHelper)
{
$this->markdownHelper = $markdownHelper;
}
// ... lines 18 - 29
}

Symfony's container does not instantiate this service until and unless you actually use it during a request. For example, if we try to use MarkdownHelper in a controller, the container will, of course, instantiate MarkdownHelper and pass it to us.

But, in a different controller, if we don't use it, then that object will never be instantiated. And... that's perfect! Instantiating objects that we don't need would be a performance killer!

Twig Extensions: Always Instantiated

Well... Twig extensions are a special situation. If you go to a page that renders any Twig template, then the AppExtension will always be instantiated, even if we don't use any of its custom functions or filters. Twig needs to instantiate the extension so that it knows about those custom things.

But, in order to instantiate AppExtension, Symfony's container first needs to instantiate MarkdownHelper. So, for example, the homepage does not render anything through markdown. But because our AppExtension is instantiated, MarkdownHelper is also instantiated.

In other words, we are now instantiating an extra object - MarkdownHelper - on every request that uses Twig... even if we never actually use it! It sounds subtle, but as your Twig extension grows, this can become a real problem.

Creating a Service Subscriber

We somehow want to tell Symfony to pass us the MarkdownHelper, but not actually instantiate it until, and unless, we need it. That's totally possible.

But, it's a little bit tricky until you see the whole thing put together. So, watch closely.

First, make your class implement a new interface: ServiceSubscriberInterface:

42 lines | src/Twig/AppExtension.php
// ... lines 1 - 6
use Symfony\Component\DependencyInjection\ServiceSubscriberInterface;
// ... lines 8 - 11
class AppExtension extends AbstractExtension implements ServiceSubscriberInterface
{
// ... lines 14 - 40
}

This will force us to have one new method. At the bottom of the class, I'll go to the "Code"->"Generate" menu - or Command+N on a Mac - and implement getSubscribedServices(). Return an array from this... but leave it empty for now:

42 lines | src/Twig/AppExtension.php
// ... lines 1 - 6
use Symfony\Component\DependencyInjection\ServiceSubscriberInterface;
// ... lines 8 - 11
class AppExtension extends AbstractExtension implements ServiceSubscriberInterface
{
// ... lines 14 - 34
public static function getSubscribedServices()
{
return [
// ... line 38
];
}
}

Next, up on your constructor, remove the first argument and replace it with ContainerInterface - the one from Psr - $container:

42 lines | src/Twig/AppExtension.php
// ... lines 1 - 5
use Psr\Container\ContainerInterface;
// ... lines 7 - 11
class AppExtension extends AbstractExtension implements ServiceSubscriberInterface
{
// ... lines 14 - 15
public function __construct(ContainerInterface $container)
{
// ... line 18
}
// ... lines 20 - 40
}

Also rename the property to $container:

42 lines | src/Twig/AppExtension.php
// ... lines 1 - 5
use Psr\Container\ContainerInterface;
// ... lines 7 - 11
class AppExtension extends AbstractExtension implements ServiceSubscriberInterface
{
private $container;
public function __construct(ContainerInterface $container)
{
$this->container = $container;
}
// ... lines 20 - 40
}

Populating the Container

At this point... if you're totally confused... no worries! Here's the deal: when you make a service implements ServiceSubscriberInterface, Symfony will suddenly try to pass a service container to your constructor. It does this by looking for an argument that's type-hinted with ContainerInterface. So, you can still have other arguments, as long as one has this type-hint.

But, one important thing: this $container is not Symfony's big service container that holds hundreds of services. Nope, this is a mini-container, that holds a subset of those services. In fact, right now, it holds zero.

To tell Symfony which services you want in your mini-container, use getSubscribedServices(). Let's return the one service we need: MarkdownHelper::class:

42 lines | src/Twig/AppExtension.php
// ... lines 1 - 4
use App\Service\MarkdownHelper;
// ... lines 6 - 11
class AppExtension extends AbstractExtension implements ServiceSubscriberInterface
{
// ... lines 14 - 34
public static function getSubscribedServices()
{
return [
MarkdownHelper::class,
];
}
}

When we do this, Symfony will basically autowire that service into the mini container, and make it public so that we can fetch it directly. In other words, down in processMarkdown(), we can use it with $this->container->get(MarkdownHelper::class) and then ->parse($value):

42 lines | src/Twig/AppExtension.php
// ... lines 1 - 4
use App\Service\MarkdownHelper;
// ... lines 6 - 11
class AppExtension extends AbstractExtension implements ServiceSubscriberInterface
{
// ... lines 14 - 27
public function processMarkdown($value)
{
return $this->container
->get(MarkdownHelper::class)
->parse($value);
}
// ... lines 34 - 40
}

At this point, this might feel like just a more complex version of dependency injection. And yea... it kinda is! Instead of passing us the MarkdownHelper directly, Symfony is passing us a container that holds the MarkdownHelper. But, the key difference is that, thanks to this trick, the MarkdownHelper service is not instantiated until and unless we fetch it out of this container.

Understanding getSubscribedServices()

Oh, and to hopefully make things a bit more clear, you can actually return a key-value pair from getSubscribedServices(), like 'foo' => MarkdownHelper::class:

class AppExtension extends AbstractExtension implements ServiceSubscriberInterface
{
    // ...
    public static function getSubscribedServices()
    {
        return [
            'foo' => MarkdownHelper::class,
        ];
    }
}

If we did this, it would still mean that the MarkdownHelper service is autowired into the mini-container, but we would reference it internally with the id foo.

If you just pass MarkdownHelper::class as the value, then that's also used as the key.

The end result is exactly the same as before, except MarkdownHelper is lazy! To prove it, put a die statement at the top of the MarkdownHelper constructor.

Now, go back to the article page and refresh. Not surprising: it hits the die statement when rendering the Twig template. But now, go back to the homepage. Yes! The whole page prints: MarkdownHelper is never instantiated.

Go back and remove that die statement.

Tip

There is a better way for creating lazy-Loaded Twig extensions since Twig v1.26. First of all, create a separate class, e.g. AppRuntime, that implements RuntimeExtensionInterface and inject MarkdownHelper object there. Also, move processMarkdown() method there:

namespace App\Twig;

use App\Service\MarkdownHelper;
use Twig\Extension\RuntimeExtensionInterface;

class AppRuntime implements RuntimeExtensionInterface
{
    private $markdownHelper;

    public function __construct(MarkdownHelper $markdownHelper)
    {
        $this->markdownHelper = $markdownHelper;
    }

    public function processMarkdown($value)
    {
        return $this->markdownHelper->parse($value);
    }
}

And then, in AppExtension, remove MarkdownHelper at all and point the cached_markdown filter to [AppRuntime::class, 'processMarkdown'] instead:

namespace App\Twig;

use Twig\Extension\AbstractExtension;
use Twig\TwigFilter;

class AppExtension extends AbstractExtension
{
    public function getFilters(): array
    {
        return [
            new TwigFilter('cached_markdown', [AppRuntime::class, 'processMarkdown'], ['is_safe' => ['html']]),
        ];
    }
}

That's it! Now our Twig extension does not have any direct dependencies, and AppRuntime object will be created only when cached_markdown is called.

Here's the super-duper-important takeaway: I want you to use normal dependency injection everywhere - just pass each service you need through the constructor, without all this fancy service-subscriber stuff.

But then, in just a couple of places in Symfony, the main ones being Twig extensions, event subscribers and security voters - a few topics we'll talk about in the future - you should consider using a service subscriber instead to avoid a performance hit.