NYCPHP Meetup

[Rob Marscher]

On Nov 30, 2007, at 12:13 AM, John Campbell wrote:
>> include_once is a real performance drag.  You should use better  
>> program
>> logic to make it possible to use a regular include call.
>
> That is news to me.  Why is include_once a performance drag?

This is a pretty controversial topic.

The theory about include_once being a performance drag is because it  
has to do file system checks to get the real path of the file to make  
sure it hasn't already included it.  There were major issues with this  
in early versions of PHP5, but has since been resolved.

> What is the better programming logic, that doesn't just duplicate  
> the behavior?

I find it difficult to not use include_once/require_once in a large  
application.  You can use __autoload or something like this:

if (!class_exists('SomeClass') {
	require 'SomeClass.php';
}
or
if (!function_exists('SomeFunction') {
	require 'SomeLibrary.php';
}

That requires some good naming conventions and file system mapping to  
create efficiently.  Otherwise you end up with some crazy switch  
statement.

In addition to that, it puts conditional logic around the includes.   
 From what I understand, opcode caches like APC scan the code for  
includes to cache, but won't use the cache very well if the include is  
inside any kind of conditional logic.  Therefore, I've stuck with my  
include_once/require_once statements which are almost all outside of  
any conditional logic.

But this whole thing has been hazy to me and I have a feeling the php  
internal developers might have conflicting feelings on it.

I just did a little web searching and found this guys blog.  Pretty  
cool stuff... he obviously knows what's going on here.  I recommend  
reading all the posts from bottom to top.  Almost half of them apply  
to this include problem.  He wrote a tool that analyzes your code to  
determine how the Zend engine and APC are handling your includes.   
It's called Inclued:
http://t3.dotgnu.info/blog/php/