On 1/23/07, Khalid B <kb@2bits.com> wrote:
+1 from me too.
I think the potential for speed is huge for this patch. The less files we load the
faster Drupal will be for sure.
Some comments:
- I am torn about the .register file though. Why? Because we are moving towards too
many files already (first .install, then .info, then .register, then .foo, ad nauseum).
Perhaps this is overcome by one hook only modulename_register() or
modulename_callbacks().
- 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.
- In development mode, the compile step is dynamic, making the site slower,
but guaranteed to be "fresh".
- We can even make the development mode be the default if we want, and
the compile step is an optimization step for sites who need it.
More thinking aloud:
The compile step can be done on-demand as well, but requires the web server
to have write access to the master .callback. It can detect if the time of the
files have changed and then generate the master .callback file. Much like we
do the menu cache in the database today.
Heck, we can store the callbacks in the database as well. Not sure if that is
faster or not. We already store the modules and themes in the system table.