[drupal-devel] Speed of Drupal, memory usage, and all that stuff
Hi there, those of you who have been following Drupal's development for some time will know that I've always been interested in making Drupal faster. Some other people have expressed interest in making Drupal use less memory, especially on the admin/modules page where currently all present modules are included. I've recently experimented a bit and came up with a solution that achieves both goals. You can look at it in the speed-drupal directory in my sandbox. There is also an issue with the title "Make Drupal faster" where I described my results. I reduced the amount of lines of code that gets included and parsed by PHP on each page call by moving most of a module's code into .inc files and only leaving small wrappers for the functions in the .module file. The result is fully functional and achieves both goals. I still don't like it much because having both a wrapper and a function in a .inc file isn't really nice. That is why I thought about another approach: On calling admin/modules we should not include the modules, but include a small .functions file. This file should (for each module) tell us which functions are defined in which file. By this approach it would be possible to split each file up in a number of small files and still let Drupal know where the functions are defined. The array of functionname->file associations will be stored and if a function is called through a wrapper such as module_invoke Drupal would be able to include the neccessary file and execute the function. This would of course require that module authors call all external functions through module_invoke. A second step of optimisation would be to define the operation of each hook that is implemented. For example a module might only implement the 'delete' operation of the _nodeapi hook. Then it would not be neccessary to include any file if the 'view' operation of that hook is invoked. This is very important for the _help hook which has a lot of code[1]. As a closing remark I need to state that the whole code parsing issue is of little concern if you run your own server and can install a PHP cache. Those caches keep the generated byte code in memory (either virtual or in files) and thus make all this effort pretty much unneccessary. Since I do now run my own server, I have little personal use for either of the outlined approaches and will only work on it if I see good chances to get it into Drupal 4.7. Discussion is welcome. Cheers, Gerhard [1] Actually I think we could get rid of the help hook for most help messages by using drupal_set_message with a help status (drupal_set_message('I am your helpfull message', 'help')).
Instead of having each module add a .functions file how about quickly string parsing .module files for function names? Upon encountering a new .module drupal grabs all function names (not compiled by PHP but by reading it in as a text file) and caches them in the database. This way drupal will have its list of module functions cached, no PHP compile is necessary until functions are required, and module developers won't have to change or add anything. Gerhard Killesreiter wrote:
On calling admin/modules we should not include the modules, but include a small .functions file. This file should (for each module) tell us which functions are defined in which file. By this approach it would be possible to split each file up in a number of small files and still let Drupal know where the functions are defined. The array of functionname->file associations will be stored and if a function is called through a wrapper such as module_invoke Drupal would be able to include the neccessary file and execute the function. This would of course require that module authors call all external functions through module_invoke.
Instead of having each module add a .functions file how about quickly string parsing .module files for function names? Upon encountering a new .module drupal grabs all function names (not compiled by PHP but by reading it in as a text file) and caches them in the database. This way drupal will have its list of module functions cached, no PHP compile is necessary until functions are required, and module developers won't have to change or add anything.
Sadly, the PHP tokenizer is only available since PHP 4.3.0 for sure. Goba
On Sun, 6 Feb 2005, Matt Schwartz wrote:
Instead of having each module add a .functions file how about quickly string parsing .module files for function names? Upon encountering a new .module drupal grabs all function names (not compiled by PHP but by reading it in as a text file) and caches them in the database. This way drupal will have its list of module functions cached, no PHP compile is necessary until functions are required, and module developers won't have to change or add anything.
This is the alternative approach for which I already have a (somewhat dirty) parser. ;) The problem is that the most elegant way to write such a parser involves using php 4.3.x. If we only want the function names, a php 4.1 version could be developed, though. Cheers, Gerhard
This is the alternative approach for which I already have a (somewhat dirty) parser. ;)
The problem is that the most elegant way to write such a parser involves using php 4.3.x. If we only want the function names, a php 4.1 version could be developed, though.
Would that resolve things like? /* this is defined in another file function foobar_foo() { } */ I doubt. Contrib modules might have such code though, especially modules under development (head). Also I have authored patches before with code like: if (!function_exists('foobar_foo')) { function foobar_foo() { ... } } Which is even hard for the tokenizer to parse... Goba
On Sun, 6 Feb 2005, Gabor Hojtsy wrote:
This is the alternative approach for which I already have a (somewhat dirty) parser. ;)
The problem is that the most elegant way to write such a parser involves using php 4.3.x. If we only want the function names, a php 4.1 version could be developed, though.
Would that resolve things like?
/* this is defined in another file function foobar_foo() { } */
Probably not.
I doubt. Contrib modules might have such code though, especially modules under development (head).
Well, then developers need to learn a bit about cvs. Uncommented code is evil.
Also I have authored patches before with code like:
if (!function_exists('foobar_foo')) { function foobar_foo() { ... } }
Which is even hard for the tokenizer to parse...
If you write: if (!function_exists('foobar_foo')) { function foobar_foo() { ... } } It should be possible. Cheers, Gerhard
participants (3)
-
Gabor Hojtsy -
Gerhard Killesreiter -
Matt Schwartz