On 1/23/07, Jeremy Epstein <jazepstein@gmail.com> wrote:
On 1/24/07, Khalid B <kb@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.