Speed up autowiring to not use reflection at run time

[marius-ciclistu]

I've been thinking at this for the past months now and today I finally put together a POC for it.

macropay-solutions/maravel-framework#34

The idea is to move the reflection at deploy time from run time for the autowiring.

I would be happy to hear some thoughts on this.

Thank you.

Update
This does not include instantiations.

[mbabker]

What is the practical problem you are solving with this? What benchmarks have you run to indicate that this is a vital change necessary for applications using your fork of the Laravel framework versus this being a theoretical concern?

Laravel uses a runtime-based dynamic dependency injection container, which means it is designed to run without a build step. How does your modifications affect this behavior? If you're this concerned about the performance of the container, why not evaluate incorporating compiled containers such as Symfony's DependencyInjection component or projects like PHP-DI? How do your changes impact the purpose-built dynamic functionality of the container (such as the Container::makeWith() method)?

Instead of rewriting the container internals, have you evaluated other practices such as manually defining service factories, which would also bypass autowiring for supported use cases?

If I'm being honest, if you don't like Laravel's dynamic container, given how deeply rooted the container is into the framework, you're probably better off creating another toolkit that doesn't rely on Laravel's dynamic container.

[marius-ciclistu]

Thank you for taking the time to reply.

I will answer to the question that seem to not be rhetorical :)

The container make or mareWith are not touched by this. Only the methods autowiring are in the scope of this change. Any class instantiation via DI is not in this POC's scope.

I liked laravel over symfony, that is why I try to improve it without relying on octane.

The boot method of each provider is called via reflection for example.

Also the controller method that handles the request.

If this last one happens just once/request, the boot methods are many per request, even in deferred providers.

Any small amount of time that is traded for functionality, if repeated multiple times, can become a brake for response time, like the excessive set calls that are happening when using casts, including the number of times getCasts is called, which was discussed already in other threads.

That was the real case scenario benchmark that inspired me. If a getCasts called 20k times generates seconds of delay because getCasts has an if statement and a merge call, then these kind of improvements can make a difference for serious enterprize companies that don't like octane's limitations.

[marius-ciclistu]

@mbabker Benchmarks https://marius-ciclistu.medium.com/maravel-framework-10-61-9-benchmarks-vs-lumen-and-laravel-af0543430b41