I usually set a constant, either manually or like this:

define( ROOT , dirname(__FILE__));

Then do

require ROOT .  /include/file.php ;

This is the best method for 99% of cases:

include(dirname(__FILE__)."/includes/myscript.php");

This ends up being an absolute path, which means it will ignore include_path, which is a known source of a large number of include related bugs in my experience...

Performance wise though, I doubt there s much difference between absolute and relative paths. This is a sort of micro optimisation that means nothing in the long run. There will generally only be 2-3 things in include_path unless you add more in. The two usual culprits are ./ and the path to wherever pear is installed.

I wrote a simple speed test script using microtime(true). It tests the following five including methods with one million iterations:

// Absolute path.
include( /home/ftpuser/public_html/includes/myscript.php );

// Predefined path.
define( PATH ,  /home/ftpuser/public_html/includes/ );
include(PATH .  myscript.php );

// Relative path.
include( myscript.php );

// Using set_include_path().
set_include_path( /home/ftpuser/public_html/includes/ );
include( myscript.php );

// Superglobal path.
include(dirname(__FILE__) .  /myscript.php );

Which gave the following results (in seconds):

    Absolute path:            263.222
    Predefined path:          263.545
    Relative path:            301.214
    Using set_include_path(): 302.396
    Superglobal path:         269.631

My opinion based on these results is to use a predefined path, because it s the fastest only surpassed by an absolute path. However, an absolute path has the drawback that it must be altered in every file when a change is necessary.

Hope this helped. :)

P.S.
define and set_include_path() were used only once during execution of the script (they are located outside of the loop).

Definitely don t hard-code your paths, like option two. A good alternative is:

define( BASE_DIR ,  /home/ftpuser/public_html/includes );
include(BASE_DIR .  /myscript.php );
include(BASE_DIR .  /myscript2.php );
include(BASE_DIR .  /myscript3.php );
include(BASE_DIR .  /myscript4.php );

Considering you ll probably have somewhere between 5 and 50 includes (I m guessing), I wouldn t really worry about it. Just go with relative paths. The include time difference won t even be noticable. If you re developing a big web application and will have hundreds, that might be another story...

I tend to setup my include directories / libraries by setting the include path on the initialisation of my app.

set_include_path("/home/ftpuser/public_html/includes");
include("myscript.php");

The zend framework does something similar to load the library classes.

when not using an absolute path, php tries to find the file in all include paths until it finds a match.

as many include paths can be added as you like, so this could , in rare cases, cause the script to be slow.
If you are including many files (for instance to initialize a framework) using absolute paths could speed up the script a little...

I think it could also cause complications when the same relative path/filename pare occur multiple times on the filesystem, and thus php selects the first occurence, when you might need another occurence

The most important thing is to arrange the include paths so that the largest amount of require/include-calls are trapped in the first mentioned path when not including a file via an absolute path in the first place.

Relying on including everything via an absolute path is hard to maintain because changing the path of your library means individually changing all those files refering to it instead of changing the include path in one place.

It would be good for you to test all methods by checking the time it takes to execute each, personally I have never worried about it and just used relative paths.

I guess absolute paths would be slightly faster, it might be worth wondering what happens in an error, will it spit out your full file path to the users screen (obviously turn error_reporting off) and will this cause a security risk?