После прочтения о том, как сеансы PHP на основе файлов не являются лучшими для производительности, мне кажется, что я думаю. Означает ли это, что скрипт PHP, включающий множество файлов, также плох? Так как он содержит файл или отличается от того, как извлекаются файлы данных сеанса?
Вы должны использовать spl_autoload_register () и ООП. Таким образом, независимо от того, насколько мал ваш проект в настоящее время или насколько он будет развиваться со временем (и было бы глупо исключать эту возможность), PHP будет включать только то, что ему нужно, не больше и не меньше.
Это идеальный ориентированный на будущее баланс между использованием RAM во время работы, поддерживаемостью кода и эффектами времени ожидания жесткого диска, я бы сказал, при условии, что вы правильно модулируете свой код (и здесь помогает XDebug ).
Сказав это, это подразумевает плохое включение неиспользуемых файлов.
Включение файлов, независимо от того, в каком направлении (spl_autoload_register () или иначе), должно выполняться с абсолютными путями из-за директивы include_path php.ini, которую PHP будет искать для ваших файлов при использовании относительных путей.
И небольшая дополнительная заметка о том, почему «включить« foo.php »работает как« include »./foo.php» («обычный» способ включения файлов): это потому, что каталог «.» по умолчанию является частью include_path.
Я думаю, что все, кто играет с PHP, доходят до того, что их библиотеки становятся большими, и беспокоиться о производительности.
Мой опыт заключается в том, что да, если вы всегда загружаете все свои библиотеки, тогда это собирается съесть драгоценную память (из которой вам выделяется только фиксированное количество мегабайт на процесс). У меня были файлы исходного кода весом 300-400 кб (с комментариями), которые потребляли 2-3 МБ на экземпляр сценария. Видя, что скрипт получает всего 16-32 МБ со многими общими хостами, это много . Кроме того, обработка таких огромных файлов часто происходит до половины секунды за запрос, что слишком много.
Таким образом, разделение, безусловно, необходимо, и легко сделать с Autoload и супругами. Ознакомьтесь с моим ответом на этот вопрос за несколько предложений о том, как разделить ваш код с умом. Существует также ссылка на вопрос о том, как организовать большой проект PHP , который дал большие результаты. Я сейчас сам разбираюсь в идеальной структуре и еще не сделан. 🙂
Это не так уж плохо. Об этом может свидетельствовать тот факт, что никто не пытался создать компилятор, чтобы сделать все PHP-приложение одним скриптом.
Если вы действительно использовали функцию microtime для PHP, чтобы измерить, сколько времени потребовалось, это будет в миллиардных долях секунды.
Как писал Chacha102, это не так уж плохо.
Но это также зависит от ваших реальных файлов сценариев.
На практике вы должны профилировать свой код, Xdebug отлично подходит для этого.
Чтобы уточнить: профиль и сравнение. Избегайте большого количества небольших файлов сценариев, если можете, но все равно сохраняйте свой исходный код (один скрипт с тысячами строк не удобен для редактирования). Профилировщик даст вам несколько цифр, чтобы найти хороший баланс.
Лично у меня всегда было больше проблем с данными, обрабатываемыми страницами, а не размером и количеством исходного файла. Тем не менее, я пишу сильно параметризованный код в абстракционных слоях (думайте об этом как о противоположном программировании cut-n-paste), поэтому очень много работы выполняется одним и тем же кодом, просто изменяя полдюжины простых параметров.
Включение большого количества небольших файлов менее эффективно, чем включение большого файла, поэтому существуют механизмы кэширования, такие как APC.
Другим вариантом является «ленивый» включить файлы, например, require_once их перед их использованием (пример создания экземпляра класса), так что вся загрузка неиспользуемых включений не будет (вроде).
Я использовал функцию Zend об этом (зарегистрировать автозагрузку), но я не знаю, является ли она общей для php или если она не существует, а существует для других фреймворков …