Optimize performance using code generation

casey - have you seen #345118: Performance: Split .module files by moving hooks and #340723: Make modules and installation profiles only require .info.yml files? I think much of what you're talking about other than the actual code generation is discussed there.

Being able to group all $module_nodeapi_load() and $module_form_alter() into a single file per hook sounds interesting, but I don't see how you'd get round the security issue of allowing Drupal write access to itself, nor the issue of duplicate function declarations between the original file and the hook.

Additionally, many modules implement upwards of 10 hooks each (not to mention using their API functions within hooks, which Drupal can't know much about, requiring the .module to be loaded too anyway. So at a certain point, the number of aggregated hook files which would need to be loaded might well end up equivalent to the number of .module files (or whichever files we end up loading when things have been split up properly for the registry) - and we wouldn't end up gaining anything. I think this issue is better handled in the two existing patches - where we can set up good conventions for contrib modules to follow and make improvements pretty much just by moving some code around. But leaving this open for more discussion.

Any solution which allows Drupal to write code to it's own directories which will subsequently be executed is going to be won't fixed - once apache has write access to those directories, then there are many potential ways code can be written to them, either from inside or outside Drupal itself depending on configuration. See the massive effort which went in to making http://drupal.org/project/plugin_manager into a secure solution for some of the arguments around this.

There is no code in here and it doesn't look as if we'd get any. There rest can be dealt with in #345118: Performance: Split .module files by moving hooks.

I think it should be a contrib module.

subscribe

subscribing

Mm..
Sounds interesting. Curious on how this is gonna turn up.
@casey, any progress on this one ?

This is almost certainly a contrib project, but leaving open.

Sorry for my PHP/Apache etc. technical lackings, but in general:

Normally C programming (assembly language compiling) is much faster than basic; its important to compile everything when the program/module is ready to the assembly language form.

So how about Drupal, PHP in general? To me leaving a program in human language, sounds amateuristic. But those were ideas in the beginning of programming, for me some lblue monday long time ago.

Then indeed, Drupal is amazingly slow, considering the speed of a computer/server and other webware. Ofcourse only installing the basic core functions will be much faster. But I loaded my install with a lot of mods (in the lower hundreds, but many mods should be combined) to make some supersite. Not even that many, considering that there are thousands of Drupel mods. It took me years (by other reasons too) to get over this barrier of Drupal being nasty to accept installations, because it is slow. I had to put my memory up to 96M (now 500M), script time to 300. But that didn't work untill I added a seemingly undocumented rule in de settings.php for that script time too. Yes, something like cgi-php, I selected on Bluehost and I'm not sure if thats working now. For the normal php I did:

.htaccess:
php_value memory_limit 500M
php_value max_execution_time = 300
php_value max_input_time = 600

#php.ini:
max_execution_time = 300
memory_limit = 500M
max_input_time = 600

settings.php:
ini_set('memory_limit', '500M');
ini_set('max_input_time', '600'); (own idea; not documented?)
ini_set('max_execution_time', '300'); (own idea; not documented?)

Now most modules are active someway, my Drupal is very, very slow. It surpises me that my browser accepts these long times, but other users might have that problem indeed, or just walk out of this not wanting to wait that long.
(yeah, I have Bluehost, a dedicated probably is much faster)
I'm really amazed that experienced programmers -what I'm not- let this severe problem going on for years. Or did I miss something like nice theory, but in practice?

Anyway, just googling on this, first page:
* Compiling PHP and Apache 2 from source on Linux OS http://www.web-tech-india.com/articles/php/compiling_php_apache/
* Roadsend PHP compiler http://en.wikipedia.org/wiki/Roadsend_PHP
* phc -- the open source PHP compiler http://www.phpcompiler.org/
* http://en.wikipedia.org/wiki/PHP#Speed_optimization
Speed optimization
As with any interpreted language, PHP scripts are stored as human-readable source code and are compiled on-the-fly by the PHP engine. In order to speed up execution time and not have to compile the PHP source code everytime the webpage is accessed, PHP scripts can also be stored in binary format using PHP compilers such as phc and roadsend.
Code optimizers aim to reduce the runtime of the compiled code by reducing its size and making other changes that can reduce the execution time with the goal of improving performance. The nature of the PHP compiler is such that there are often opportunities for code optimization, and an example of a code optimizer is the eAccelerator PHP extension.
Another approach for reducing overhead for high load PHP servers is using an Opcode cache. Opcode caches work by caching the compiled form of a PHP script (opcodes) in shared memory to avoid the overhead of parsing and compiling the code every time the script runs. An opcode cache, APC, will be built into PHP 6. Opcode caching is also available in Zend Server Community Edition.

Sorry for my long reply, but I like to make the picture as complete as possible. So I hope for the feedback and OFCOURSE THIS NEW PROJECT/MODULE.

Is this an official project already? If not, how?

Thansk & good luck!

ClearXSClearXS, this is not the place to discuss this, but I can understand how you got mislead by the title. Those links you pasted are about technologies that need to be configured on the server site. If you know what you're doing, Drupal can be very fast. Of course you need decent hardware and some knowledge, but the same holds for every other major software product. Of course, you don't get a Porsche if you pay for a Citroën 2CV, but c'est la vie.

The core developers spend a LOT of time on performance optimizations. Plus, there are a lot of contrib projects that deal with performance. Have a look at some of the performance projects: http://drupal.org/taxonomy/term/123
Especially the following ones

http://drupal.org/project/Cacherouter
http://drupal.org/project/apc
http://drupal.org/project/memcache
http://drupal.org/project/fastpath_fscache

First, what you should do is identify your problem. First step should be to find out if it's the time PHP spends on the code or the database connections and querying thats pulling your site down. Second step is to invest some time to learn about possible optimizations.

Many thanks! Indeed, it wasn't the proper place, but now this page is one of the most complete; so many others and I will easily get to this info again by a Google or Drupal search. However, think I just found the proper page:
Drupal caching, speed and performance http://drupal.org/node/326504
If so; that is the place where all this sort of info should be centralized and edited into (anyone can edit there).

Interesting news, I think: Facebook has recently open sourced a new PHP compiler:

http://developers.facebook.com/news.php?blog=1&story=358

PS: Sorry, if this is Off Topic here. :-/ I haven't found any better Drupal core issue to post this.

http://fourkitchens.com/blog/2010/02/03/making-drupal-pressflow-more-mun...

Closely related:

#1668892: Enable secure compiled information on disk
#1387776: Move some rebuilds outside of Drupal

Wonder if this is still needed with D10?

We're on the way towards deprecating procedural hooks, and everything else these days is OOP, so I think this can just be marked outdated. #3366083: [META] Hooks via attributes on service methods (hux style).