Drupal's code registry

Drupal 7 introduces a code registry - an inventory of all functions, classes and interfaces for all enabled modules and Drupal's core files. Drupal's module hooks, forms and menu callbacks all utilize the registry to load the code they need as needed. The registry stores the path to the file a given function, class or interface is defined in, and loads the the file when necessary.

The registry allows all of the code for these systems to be lazy-loaded, which cuts down on unnecessary code loading and parsing.

Modules can now move all code for these subsystems into module_name.registry.inc, and Drupal will only load it on demand. This will cut down on the amount of code loaded per request, and reduce Drupal's memory footprint.

The only file unconditionally loaded by Drupal for a given module is module_name.module. Any code the must always be available without the using the registry should be put in this file. Modules that don't have such code don't need to use a module_name.module file, and no code will be loaded up front for these modules. (Note, this is work in progress, see #345118: Performance: Split .module files by moving hooks and #340723: make modules only require .info files.)

The registry also loads classes and interfaces on demand, via php's built in class autoloading mechanism.

The registry is rebuilt when modules are enabled or disabled in order to incorporate new code or remove code from disabled modules. The registry is also rebuilt when visiting admin/build/modules. If you are developing new code, make sure to rebuild the registry regularly so that new resources are incorporated. Rebuilding an existing registry to incorporate new changes is not that expensive, as the registry will not reparse files that have the same path and md5 sum as the last build.

As the registry is database-backed, there are several layers of caching in place to keep the number of queries as low as possible.

First, all registry lookups are cached per registry rebuild. Even on registry rebuild, the parts of this cache that correspond to files that haven't changed is maintained, making for a very high hit rate. This cache can be cleared via the 'Clear all caches' form on the performance settings page.

The second layer of caching revolves around hook implementations. When the registry is built, we store possible hook implementation information with each resource. This allows us to fetch all modules that implement a hook with a single query, and cache this information between registry rebuilds.