A bit of history.

JAVA used to work in this way:

EntityManager em= (EntityManager) ctx.lookup("java:/comp/env/jdbc/MyLocalDB");

where lookup acts as the dispatcher.

However, this way of working was discarded a decade ago.

JAVA, has a meaning to work in that way because JAVA has a container and the lifecycle of the classes and objects are different.

JAVA (since 1.5) moved as follow:

@PersistenceContext(unitName = "MyLocalDB")
    private EntityManager entityManager;

The instance of an object is “injected” into the code using this operation. JAVA also owns container to objects pre-created (instance pool) because each object could (and is) reutilized by multiple instances. The goal is to avoid to create objects constantly.

Now about Laravel. Laravel is copying an old way of work. And worst, it is using the same old way but without any real purpose, there is no reusability. PHP works creating a whole new memory per request, including the containers (JAVA works per application, request, session,etc.)

‘In the case of JAVA, the object is created once per application. Sometimes the same object is reused by many instances and it could last days of life. In PHP, the object is created per request and usually, the lifecycle is seconds. So, PHP is constantly creating and destroying objects. The use of dispatcher does not change it at all, objects are created constantly, including the pool of instances.

PHP has many ways to create a singleton, so it does not need to create a dispatcher where a simple “new class” could do the same (minus the boilerplate and overhead”.

It is an old benchmark but the trend is still valid

Why PHP is slower?

PHP is not a slow language (and it’s fast with opcache) but most frameworks are slower.

Now about your question, where is the dispatcher?

PHP could work (and works better) without dispatcher. The dispatcher is bad for PHP.