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. 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.