There's been a long thread the last couple of weeks covering require_once and some rather crazy ideas to change the PEAR standards to do all sorts of strange things to load code up.
What is most ridiculus is the benchmarking that is being done to 'prove' that we should all move our code loaders to some 'allfiles.php' and we are magicially going to running be 15% faster.
What this whole concepts fails to put into place is loading all the PHP files up, either tiered one to another or all from one place is such a small part of a PHP page responding from a request.
Think of what is happening when you look at this page.
- You start by looking at a bootstrapper (that sets config option) - probably quite quick as it just set's some variables.
- Then you run into the Framework class - that works out which file to load based on the URL you are typing. - This does quite a bit of text maniplation, making best guesses about where things might be. (this is quite generic and could be made specific to the application quite easily)
- We then do the page action stuff, like pulling data from databases which requires quite a few PEAR libraries. And does some really slow crap like connecting to databases and pulling data. This stage probably does far to many queries and pulls down to much data that it doesnt use.
- Then we do output stuff, Normally we are using a compiled template, (so we dont load all the template parsing code - well at least we save a bit of effort here). so we need to pull down at least the Flexy class, then the compiled template.
Now looking at that whole process and thinking it's a bit slow, You would probably go through the following steps to optimize it.
- replace it with a staticly generated page!!!
Well, yeah, that's it!....
Only kidding... - but if you do this to a normal page, you would probably want to do the following
- reduce / remove database calls
- cache as much as possible.
- reduce / remove libraries needed and code used.
- move any data intensive code into C
- use an opcode cacher.
At no point would you get so silly that you would re-jig the 'require_once' calls just to get 15% saving on the code loading component, because wait for it..... the code loading component of your application (when using APC) would take such an insignificant percentage of the total running time.
Working out how to remove a whole file or pre-process some bit of data would be a far better use of your time. And if you where running a team focusing on this you would probably have fired the guy who wasted all that time on such a pointless task as moving the require_once lines around.
Sounds like moving the deck chairs on the titanic?
Comments
PEAR performance optimisation?
I can understand the allfiles.php argument. But we've already seen there are any number of solutions, quotes were made off the bat ignoring how require_once now works in PHP5.2.x, two benchmarks which disagree, etc.
Like yourself, I don't see allfiles.php as a solution. It's something I'd expect a programmer to create themselves if they were really truly needful of such a performance optimisation. Isn't this what build tools are so good at? I've been doing similar stuff using Phing for years...
I also see a lot of discussion around hard it is to set include_paths. I know a lot of inexperienced programmers exist but catering to their fumbling first steps into PHP doesn't seem a reasonable course of action. Direct them to documentation - they'll learn something new. Even better, put together a "install" doc which highlights these sort of startup and go issues and package it with every package. "INSTALL" anyone?
its about flexibility
Hi Alan,
The point behind this proposal is that it adds flexibility as you decouple the class loading strategy from the implementation. This will enable everyone to pick their preferred approach.
The speed freak will only load exactly those file he needs at the very beginning of his script. These people will use an opcode cache. They will also have done all of the above mentioned optimizations to cut down on db traffic etc. They will be very happy with this change.
Now the people that currently ran into issues because their provider did not even allow them to do set_include_path() or which simply have not gotten far enough in their PHP book, will also have another option that might be slightly more intuitive at the very beginning. This will ensure that they do not drop PHP and run over to Ruby :)
The people that were happy with how things are today simply drop in a trivial underscore to slash replacement __autoload() with a require_once and everything will be good. There is a tiny bit of overhead from the __autoload() call, but they benefit from not having to load unnecessary classes, which they would in today's setup (like Exceptions and other optional classes).
So the point: Every single group stands to gain from this proposal.
speed test results
I ran some tests to see what's faster: require_once() vs require() and relative_path vs absolute_path.
METHODOLOGY:
The script (test.php):
\\php
function getmicrotime()
{
list($x,$y) = explode(' ',microtime());
return ($x+$y);
}
$start_time = getmicrotime();
/*
* Uncomment one at a time.
* sql_server.inc only contains define() statements.
*/
//require('/www/includes/example.com/code/conf/sql_servers.inc');
//require('../../includes/example.com/code/conf/sql_servers.inc');
//require_once('/www/includes/example.com/code/conf/sql_servers.inc');
//require_once('../../includes/example.com/code/conf/sql_servers.inc');
$end_time = getmicrotime();
$handle = fopen("/tmp/results", "ab+");
fwrite($handle, ($end_time - $start_time) . "\n");
fclose($handle);
\\
I ran ab on the test.php script with a different require*() uncommented each time:
ab -n 1000 -c 10 www.example.com/test.php
RESULTS:
(how long it took to execute 1 call to test.php):
require('absolute_path'): 0.001522074937820
require('relative_path'): 0.000859447956085
require_once('absolute_path'): 0.001737765312195
require_once('relative_path'): 0.000952602624893
When using absolute_path there are fewer stat() system calls.
When using relative_path there are more stat() system calls.
CONCLUSIONS:
Using absolute_path is almost 2 times slower than using relative_path.
Using require_once() is slower than require().
Konstantin Rozinov
