Eloquent model observer performance - laravel

Question

If I have multipile models and I working heavy with events so in my AppServiceProvider I create a observer for my models like:
class AppServiceProvider extends ServiceProvider
{
/**
* Bootstrap any application services.
*
* #return void
*/
public function boot()
{
User::observe(UserObserver::class);
User2::observe(UserObserver2::class);
User3::observe(UserObserver3::class);
User4::observe(UserObserver4::class);
User5::observe(UserObserver5::class);
User6::observe(UserObserver6::class);
User7::observe(UserObserver7::class);
User8::observe(UserObserver8::class);
User9::observe(UserObserver9::class);
}
/**
* Register the service provider.
*
* #return void
*/
public function register()
{
//
}
}
does it create some performance penalty? as If I understand the observe method correctly for every app access it will loop through all my models observers method and will match them to eloquent events so if I have 30 models observers it can cause a bad performance?
is there some clever way of declaring the observe class only when the model is in use? so instead of declaring the observers in each app access even when not needed each model will know about its observer only when its in use?

Answer 1

With model observers specifically, there is a performance impact that's greater than typical event registration. The extra overhead comes from how Laravel handles the observer event mapping. Since the events being registered are based on the existing methods, Laravel makes a minimum of 13 calls to method_exists per observer.
For just a couple of observers, that isn't a big deal. However, if you start using observers for audit trail processes and involve several models, this cost can start to add up.
As an example, I once worked on application that had four generalized observers that observed around 300 models between them (some of the models were shared by observers). This turned into over 600 Model::observe calls, and therefore over 7,800 calls into method_exists.
I've actually created a package (reedware/laravel-events) to solve this problem. You instead register observers (and other events) through a configuration file, and the events can be cached. The caching mechanism actually works for observers too (which doesn't work for Laravel out of the box), so the cost of observers becomes extremely minimal.
Alternatively, you could ditch the observer design pattern, and use the Model::creating(...) hooks within a bootable trait, or just throw custom events and register listeners for them.

Answer 2

If you use events with Laravel, the events will be registered (but not fired) on every request.
To be more precise, that the events will be registered means that User::observe(UserObserver::class); will loop through all methods of UserObserver and save them in an array of a dispatcher of the User class. Only if an update / create method through the User model is executed, the registered UserObserver method will be fired, i.e. called from the dispatcher.
So if you have 30 Models each with 5 methods in the Observer class, that would be 150 array bindings on every request to the dispatcher. However, the methods of your observer are not called during each request, only when the event fires. Thus, I don't believe that 150 array assignments will make an impact on the request time, compared to the time it takes to load a 120kb Logo or to execute query calls.
Best thing is of course to measure it for yourself. Measure the time of a request with binding the observer and without. You could use debugbar for it.
Side note: Using deferred providers won't make any difference, because you have to place the observer calls into the boot method of a provider. From the docs:
If your provider is only registering bindings in the service container, you may choose to defer its registration until one of the registered bindings is actually needed.