Is it bad practice to use the same hook twice?

Joost

4/17/23, 8:14 AM

I'm working a quite a big project and I use hook_entity_update() in three of my modules. I do this to keep my project structured and have different functions of my site in different modules.

Is it bad performance wise to have this hook called multiple times from different modules?
Since this way of working makes the number of custom modules grow, does the number of modules affect the performance of the site or is it only the code inside that can give performance issues?

816

0 + 0

hooks

Score:4

Drupal

Patrick Kenny

4/17/23, 8:42 AM

Of course you would have to benchmark your modules to get an exact answer, but generally speaking, the benefits of breaking up complex code into multiple modules separated by function is the way to go.

The performance impact of calling the hook is minimal; the larger performance impact will be whatever code the hook runs.

The number of modules does not matter nearly as much as the code that the modules are running.

Evidence: Moving from Drupal 7 to Drupal 8/9, many major Drupal modules have gone from "minimize the number of modules" to "provide many more function-specific modules that can be enabled as needed":

AdvAgg
Commerce
Metatag
Webform

TLDR: The actual code that you run in hooks/modules is way more important for performance than the fact that you are calling hooks multiple times in modules.

However, one thing you have to keep aware of is that if you organize your modules poorly, you can end up adding custom code to the same hook in multiple modules that could result in bugs, such as if you are changing the same field in hook_entity_update(). So make sure you organize your code in a way that makes it clear which modules are responsible for which functions.

As a developer, it is definitely easier to maintain custom modules when they are separated by function, especially in the case that you end up having to use some but not all of the functions/modules on multiple sites.

0 + 0

Joost

4/17/23, 9:45 AM

Thanks for the extensive answer, very clear and very helpful

Score:3

Drupal

apaderno

4/17/23, 9:55 AM

The number of installed modules may influence performance. That's why, for example, Drupal core keeps in cache the name of the implemented hooks.
Given what Drupal core does, increasing the number of installed modules would have a lower impact on performance.

The aim for developers should not be reducing the number of modules/sub-modules, but writing modules that implement a specific feature. Clearly, if implementing a feature requires few lines, probably the module should be merged with another module, especially if that module is a sub-module.

To make an example, instead of the Node and User modules, there could be a single module (called, for example, Base Content). Since those modules are normally required from the installation profile, it would reduce the number of installed modules. It could also reduce the number of implemented hooks, since (for example) node_user_predelete() could be merged with a class method or another function.
Anyway, doing so, two modules with different purposes would be merged together; the hooks could be reduced, but in some cases the code could now need to first check some conditions are met; probably more services should be lazy-loaded, which means that there would be two classes instead of one (the proxy class and the class implementing the service). Those classes would need to be synchronized with each other: Any change on the service class needs to be done on the proxy class too. (There is a script for doing that, but it works only on installed modules, which means the developer would need a local server running Drupal and remember to run the script for every lazy-loaded service.)

It's not just a matter of implemented hooks: In Drupal 9, a module that is complex enough implements many classes, some of which are service or plugin implementations. Even modules that are simple enough to just need a single route implement code in at least a class.