<br><br><div><span class="gmail_quote">On 1/23/07, <b class="gmail_sendername">Jeremy Epstein</b> <<a href="mailto:jazepstein@gmail.com">jazepstein@gmail.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On 1/24/07, Khalid B <<a href="mailto:kb@2bits.com">kb@2bits.com</a>> wrote:<br>> - Another option is to have a compiler for Drupal. Once a site is "compiled"<br>> all the modulename_callbacks() functions are written to ONE file for all the
<br>> site's modules and themes, or perhaps two files, one for core and the other<br>> for contrib. This single file (or two), can be loaded once instead of some<br>> 30 .callback or .module files, which will be faster. We then get the
<br>> benefits<br>> of Karoly's split patch as a bonus.<br><br>Why would you want to compile all the callback functions into ONE<br>file? Sure, that would reduce disk I/O, but it would mean that we're<br>not reducing our memory footprint by nearly as much as we
<br>could/should.</blockquote><div><br>By "compile", I did not mean real compilation of PHP code into <br>byte code or something. Just a pre-processing step that is Drupal<br>specific of merging all the callback definitions into one file to load
<br>(or one table in the DB).<br><br>Just the definitions, not the actual code. So, only one file (table) needs<br>to get loaded on each page view, and that contains a pointer to which <br>files contain which functions, and what callback (like what Earl said
<br>initially).<br></div><br>Loading one file is faster than loading 30 of them for every page.<br><br>Then we go to the actual file on an as needed basis, not having to read<br>all the files in as we do today.<br><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
A better option, IMO, would be to compile code based on the menu paths<br>for which that code is needed. Because of wildcards (e.g. 'node/%' is<br>just one path, rather than 'node/1', 'node/2', etc. being however many
<br>thousand paths), this will make much more sense in the Drupal 6 menu<br>system than it would for the Drupal 5 menu system. For each menu path,<br>we could have a file that is a cache of the functions needed by that<br>
path. Kind of analogous to page caching, except we're caching logic,<br>rather than output.<br><br>This would give us the best of both worlds:<br><br>1. Minimum disk I/O: we're only loading ONE file (for modules) on each
<br>page view.</blockquote><div><br>That is what I was saying, but with Earl's original idea of callbacks.<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
2. Minimum memory footprint: that one file contains ONLY the<br>functions/callbacks that are actually used on that page view.</blockquote><div><br>Exactly what I said. <br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
It would, however, have the big disadvantage of Drupal generating<br>hundreds of compiled-code cache files. Perhaps we could take advantage<br>of the cache API instead? E.g. store the compiled code for each page<br>in the database by default, but use file-based caching if that cache
<br>engine is installed, or memcached, etc.</blockquote><div><br>Not sure what the actual impact of APC and friends will be here.<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Cheers,<br>Jaza.<br></blockquote></div><br>