[development] Eliminate hooks entirely in Drupal 6

[Khalid B]

On 1/23/07, Jeremy Epstein <jazepstein at gmail.com> wrote:
>
> 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.


By "compile", I did not mean real compilation of PHP code into
byte code or something. Just a pre-processing step that is Drupal
specific of merging all the callback definitions into one file to load
(or one table in the DB).

Just the definitions, not the actual code. So, only one file (table) needs
to get loaded on each page view, and that contains a pointer to which
files contain which functions, and what callback (like what Earl said
initially).

Loading one file is faster than loading 30 of them for every page.

Then we go to the actual file on an as needed basis, not having to read
all the files in as we do today.

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.


That is what I was saying, but with Earl's original idea of callbacks.

2. Minimum memory footprint: that one file contains ONLY the
> functions/callbacks that are actually used on that page view.


Exactly what I said.

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.


Not sure what the actual impact of APC and friends will be here.

Cheers,
> Jaza.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20070123/d1003730/attachment.htm