Насколько важно не загружать неиспользуемые скрипты в PHP?

Question

На сайте, где 90% страниц используют одни и те же библиотеки, вам следует просто загружать библиотеки постоянно или загружать их только при необходимости? Другие страницы будут ajax или простыми страницами, которые не имеют никакой реальной функциональности.

Кроме того, вы должны загружать код только при необходимости? Если частично вниз по странице вам нужна библиотека, вы должны загрузить ее тогда или просто загрузить сверху. Возможно, возможно, что он никогда не попадет туда раньше из-за ошибки или неправильных данных. (Загрузка сверху облегчает понимание, но может привести к тому, что дополнительный код не понадобится.)

Мне также интересно, следует ли мне сделать библиотеки более конкретными, поэтому я не говорю, загружать код для редактирования одновременно с просмотром?

В общем, сколько мне стоит беспокоиться о загрузке кода или не загрузке кода?

Answer 1

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

Что касается загрузки библиотек, я считаю, что потеря производительности при включении ненужных библиотек во многих случаях может быть совершенно несущественной. Однако include, require, include_once и require_once являются относительно медленными, поскольку они (очевидно) обращаются к файловой системе. Если библиотеки, которые вы не используете в каждом случае, достаточно велики и обычно содержат много разных файлов, удаление ненужных включений может помочь сократить время, проведенное там. Тем не менее, эта стоимость также может быть значительно снижена за счет использования эффективной системы кэширования.

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

Наконец, если вы внесете какие-либо изменения, которые могут повлиять на производительность вашего веб-сайта, запустите некоторые тесты и профилируйте выигрыш или потерю производительности. Таким образом, вы не рискуете провести какую-то классную оптимизацию, которая просто требует слишком много времени для полной реализации или даже снижает производительность.

Answer 2

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

Есть две вещи, которые вы можете сделать, чтобы устранить такие проблемы:

1. Используйте __ autoload для загрузки ваших скриптов по мере необходимости. Это избавляет от необходимости вести длинный список «требующих» сценариев и загружает только то, что нужно для текущего запуска.
2. Используйте APC в качестве кэша байт-кода, чтобы снизить стоимость загрузки скриптов. APC кэширует скрипты в их скомпилированном состоянии и будет творить чудеса с производительностью вашего приложения.

Answer 3

Вопрос был «насколько важен».

Ответ: это НЕ важно. Если у вас уже нет дюжины серверов, на которых уже запущено это приложение, то это, вероятно, ранняя оптимизация, и, как мы все знаем, ранняя оптимизация - корень всех зол.

Другими словами: даже не беспокойтесь об этом. Есть много других вещей, чтобы оптимизировать скорость, прежде чем вы даже должны учитывать это.

Answer 4

+ 1 Голосуйте за технику автозагрузки.

Дополнительным преимуществом использования автозагрузки является то, что она устраняет потенциальную возможность злоупотребления кодом. Если что-то не получается, выведите список обратной трассировки и список «включенных_файлов», и вы получите список мест, откуда может возникнуть проблема.

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

Однажды я работал над базой кода (не моей), где присутствие определенных токенов в URL вызывало непредвиденное поведение, и поскольку код был ужасным, это был кошмар, отслеживающий причину проблемы, скрытой в факте в из 200 включенных файлов один из них переписывал весь запрос и затем вызывал «die»