Подтвердить что ты не робот

Php относительные и абсолютные пути

Я читал, что при включении php файла, когда использование абсолютных путей имеет более быстрое время обработки, чем относительные пути.

Что вы предлагаете использовать?

include("includes/myscript.php");

или

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

или даже

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

Или это то, о чем я действительно не должен беспокоиться?

4b9b3361

Ответ 1

Обычно я устанавливаю константу либо вручную, либо так:

define('ROOT', dirname(__FILE__));

Тогда do

require ROOT . '/include/file.php';

Ответ 2

Это лучший способ для 99% случаев:

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

Таким образом, это абсолютный путь, что означает, что он игнорирует include_path, который является известным источником большого числа включенных связанных ошибок в моем опыте...

Производительность мудрая, хотя, я сомневаюсь, что существует большая разница между абсолютными и относительными путями. Это своего рода микро-оптимизация, которая в конечном итоге ничего не значит. В include_path будет всего 2-3 вещи, если вы не добавите больше. Два обычных виновника: ./ и установлен путь туда, где pear.

Ответ 3

Я написал простой тест скорости script с помощью microtime(true). Он тестирует следующие пять, включая методы с миллионом итераций:

// 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');


Это дало следующие результаты (в секундах):

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


Мое мнение, основанное на этих результатах, состоит в том, чтобы использовать предопределенный путь, потому что он быстрее всего превосходит абсолютный путь. Тем не менее, абсолютный путь имеет недостаток, что он должен быть изменен в каждом файле, когда требуется изменение.

Надеюсь, это помогло.:)

P.S.
define и set_include_path() использовались только один раз во время выполнения script (они находятся вне цикла).

Ответ 4

Определенно не жестко кодируйте свои пути, как вариант два. Хорошей альтернативой является:

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');

Учитывая, что вы, вероятно, будете иметь от 5 до 50 включений (я предполагаю), я бы не стал беспокоиться об этом. Просто пойдите с относительными путями. Разница во времени не будет заметна. Если вы разрабатываете большое веб-приложение и будете иметь сотни, это может быть другая история...

Ответ 5

Я пытаюсь настроить мои каталоги include/libraries, установив путь включения в инициализацию моего приложения.

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

Структура zend делает что-то похожее на загрузку классов библиотеки.

Ответ 6

когда не используется абсолютный путь, php пытается найти файл во всех включенных путях, пока не найдет совпадение.

поскольку многие из них включают в себя пути, которые можно добавить, как вам нравится, поэтому в редких случаях это может привести к замедлению работы script. Если вы включаете много файлов (например, для инициализации фреймворка), используя абсолютные пути, можно немного ускорить script...

Я думаю, что это также может вызвать осложнения, когда один и тот же путь относительного пути/имени файла происходит несколько раз в файловой системе, и, таким образом, php выбирает первое появление, когда вам может понадобиться другое событие

Ответ 7

Самое главное - упорядочить пути include так, чтобы наибольшее количество require/include -calls попало в первый упомянутый путь, если не включать файл через абсолютный путь в первую очередь.

Полагаться на включение всего через абсолютный путь трудно поддерживать, потому что изменение пути к вашей библиотеке означает индивидуальное изменение всех файлов, ссылающихся на него, вместо изменения пути включения в одном месте.

Ответ 8

Было бы хорошо проверить все методы, проверяя время, необходимое для выполнения каждого, лично я никогда не беспокоился об этом и просто использовал относительные пути.

Я думаю, что абсолютные пути будут немного быстрее, может быть, стоит подумать, что произойдет с ошибкой, вытолкнет ли ваш полный путь к файлу пользователя (очевидно, отключит error_reporting), и это вызовет риск безопасности?