[development] Eliminate hooks entirely in Drupal 6
Jeremy Epstein
jazepstein at gmail.com
Wed Jan 24 02:28:29 UTC 2007
On 1/24/07, Khalid B <kb at 2bits.com> wrote:
> - Another option is to have a compiler for Drupal. Once a site is "compiled"
> all the modulename_callbacks() functions are written to ONE file for all the
> site's modules and themes, or perhaps two files, one for core and the other
> for contrib. This single file (or two), can be loaded once instead of some
> 30 .callback or .module files, which will be faster. We then get the
> benefits
> of Karoly's split patch as a bonus.
Why would you want to compile all the callback functions into ONE
file? Sure, that would reduce disk I/O, but it would mean that we're
not reducing our memory footprint by nearly as much as we
could/should.
A better option, IMO, would be to compile code based on the menu paths
for which that code is needed. Because of wildcards (e.g. 'node/%' is
just one path, rather than 'node/1', 'node/2', etc. being however many
thousand paths), this will make much more sense in the Drupal 6 menu
system than it would for the Drupal 5 menu system. For each menu path,
we could have a file that is a cache of the functions needed by that
path. Kind of analogous to page caching, except we're caching logic,
rather than output.
This would give us the best of both worlds:
1. Minimum disk I/O: we're only loading ONE file (for modules) on each
page view.
2. Minimum memory footprint: that one file contains ONLY the
functions/callbacks that are actually used on that page view.
It would, however, have the big disadvantage of Drupal generating
hundreds of compiled-code cache files. Perhaps we could take advantage
of the cache API instead? E.g. store the compiled code for each page
in the database by default, but use file-based caching if that cache
engine is installed, or memcached, etc.
Cheers,
Jaza.
More information about the development
mailing list