Yep unless it bogs down development, I wouldn’t worry about it.

While I don't seem to have a performance impact in production, in hindsight my question still hasn't been answered, and I fail to find the rootcause.

Most of the initialization time is spent initializing bundles and the container

If that's the case, why can't the debug toolbar specify which part causes slow initialization? I've been using php-spx trying to figure it out, and besides the Symfony\Component\EventDispatcher\Debug\TraceableEventDispatcher::dispatch (which seems debug specific), I don't really see much slowing the application down.

A clean Symfony 6.4 demo application shows me an initializiation time of 44 ms, so while I can agree it has something to do with either bundles/kernel/container, it's not easy to pinpoint.

why can't the debug toolbar specify which part causes slow initialization?

I guess this is because the profiler needs the container, so it cannot run before it is built?

Anyways if you cannot find what is slow using php-spx I doubt the profiler could help 😕

Hey @MatTheCat

I'm coming back on this after a year because I still couldn't figure it out with the profiler, SPX or debugging in Symfony kernel itself.

But that being said, I just couldn't believe it was really that "slow", so I thought of enabling opcache for development once again. I've found out 2 things:

1. I had a opcache.ini but apparently opcache.enable was never set to 1 (due to some docker environment variable misconfiguration 🤦‍♂️ ), so not only didn't opcache work on development, it was also never enabled on my production server 🙈.
2. Enabling opcache for development changed my initialization time from +/- 225 ms to +/- 40-60 ms. Safe to say production is also noticably faster now 🙃

Thanks for the help.

Ouch..! https://wiki.php.net/rfc/make_opcache_required should prevent this kind of issue in the future 🤞

the initialization time climbs up to 2200ms in dev environment
[…]
I can see it in production, but unfortunately not locally

You’re not really supposed to use the dev environment on production. If this is the only combination triggering a high initialization time, I would simply suggest to stop doing that 😁

Anyways, I guess if you wanted to profile you could do it with Xdebug or using an APM like Blackfire.

Verify that PHP Jit is active
Try to run composer --optimize --classmap-authoritative or composer -o -a
(Cf https://getcomposer.org/doc/articles/autoloader-optimization.md)
Try to Profile with Xdebug
Exemple of integration with PHPStorm: https://www.jetbrains.com/help/phpstorm/profiling-with-xdebug.html#enable-profiling-with-xdebug

I would simply suggest to stop doing that

Well, that's a sensible suggestion, I think I'll stick to that :)
I'll give xdebug and php-spx a try, though.

Thanks, @alexandre-le-borgne and @MatTheCat .

I played a little with SPX and found out that a lot of time was spent on loading files during "Symfony initialization".
It turns out that on our servers, the open_basedir ini directive had been activated, disabling the realpath cache! Every file lookup thus took more time.
The difference between prod and dev environments being that in dev, every service is stored in its own php file, rather that gathered in a single container file.
We disabled the open_basedir and everything went back to normal.