В последнее время я занимаюсь работой с PHP, и во всем коде, который я видел, люди склонны использовать несколько методов. (Они также имеют тенденцию использовать несколько переменных, но это еще одна проблема.) Мне было интересно, почему это так, и я нашел эту заметку «Вызов функции с одним параметром и пустым телом функции занимает примерно то же время, что и 7-8 $ localvar ++. Подобным вызовом метода является, конечно, около 15 $ localvar ++ операций " здесь .
Это правда, даже когда страница PHP была скомпилирована и кэширована? Должен ли я избегать использования методов в максимально возможной степени для эффективности? Мне нравится писать хорошо организованный, удобочитаемый код с методами везде, где будет повторяться блок кода. Если необходимо писать плоский код без методов, существуют ли какие-либо программы, которые будут «встроенными» методами? Таким образом, я мог бы написать хороший код, а затем уродливый до развертывания.
Кстати, код, который я просматривал, – это ядро Joomla 1.5 и несколько плагинов WordPress, поэтому я предполагаю, что они люди, которые знают, что они делают.
Примечание. Я рад, что каждый из нас вскочил на этот вопрос, чтобы говорить об оптимизации в целом , но на самом деле мы говорим об оптимизации в интерпретируемых языках. По крайней мере, некоторый намек на то, что мы говорим о PHP, будет приятным.
Я думаю, что Joomla и WordPress не являются лучшими примерами хорошего PHP-кода без обид. У меня нет ничего личного против людей, работающих над ним, и здорово, как они позволяют людям иметь сайт / блог, и я знаю, что многие люди тратят все свое свободное время на любой из этих проектов, но качество кода довольно плохое (с без обид).
Просмотрите объявления безопасности за последний год, если вы мне не верите; также предполагая, что вы ищете производительность от любого из двух, их код также не преуспевает. Так что это ни в коем случае не хороший код, но WordPress и Joomla оба превосходны на интерфейсе – довольно проста в использовании, люди получают сайт и могут делать что-то .
И поэтому они настолько успешны, что люди не выбирают их на основе качества кода, а на том, что они им позволяли делать.
Чтобы ответить на ваш вопрос о производительности, да, это правда, что все хорошие вещи (функции, классы и т. Д.) Замедляют ваше приложение. Поэтому я думаю, если ваше приложение / скрипт находится в одном файле, пусть будет так. Не стесняйтесь писать плохой PHP-код .
Как только вы расширяетесь и начинаете дублировать код, вы должны учитывать компромисс (в скорости), который приносит с собой код поддерживаемого кода. 🙂
ИМХО этот компромисс довольно мал из-за двух вещей:
Когда вам понадобится вернуться в свой код через полгода, подумайте, что если эти nano секунды сохранены, запустив его, все равно добавьте, когда вам нужно исправить неприятную ошибку (три или четыре раза из-за дублированного кода).
Вы можете делать все возможное, чтобы PHP работал быстрее. Обычно люди рекомендуют использовать кеш, например, APC . APC действительно потрясающе. Он запускает для вас всевозможные оптимизации в фоновом режиме, например, кэширование байт-кода файла PHP, а также предоставляет вам функции в пользовательской среде для сохранения данных.
Так, например, если вы анализируете файл конфигурации каждый раз, когда вы запускаете этот сценарий, диск ввода-вывода действительно критичен. С помощью простых apc_store () и apc_fetch () вы можете сохранить анализируемый файл конфигурации либо в кеше на основе файлов, либо на базе памяти (ОЗУ) и извлечь его оттуда до истечения срока действия кеша или удаления.
Конечно, APC – это не единственный кеш.
Сколько «эффективности» вам нужно? Вы даже измерили? Преждевременная оптимизация – это корень всего зла, а оптимизация без измерения ВСЕГДА преждевременна.
Помните также правила Клуба Оптимизации .
Вы должны увидеть ответы на этот вопрос: должен ли разработчик ориентироваться на читаемость или производительность?
Подводя итог консенсусу: если вы не знаете для факта (через тестирование / профилирование), что ваша производительность должна быть решена в определенной области, читаемость гораздо важнее.
В 99% случаев вам лучше беспокоиться о понятности кода. Напиши код легко проверить, понять и почерпнуть.
В тех немногих случаях, когда производительность действительно важна, скриптовые языки, такие как PHP, не являются вашим лучшим выбором. Причина в том, что многие базовые библиотечные функции в PHP написаны на C, в конце концов.
Лично, хотя может возникнуть накладные расходы для вызова функции, если это означает, что я пишу код один раз (параметризованный), а затем использую его в 85 местах, я буду дальше, потому что я могу исправить его в одном месте.
Языки сценариев, как правило, дают людям представление о том, что «достаточно хорошо» и «работает» являются единственными критериями, которые следует учитывать при кодировании.
Особенно с быстрым интерпретатором, таким как PHP, я не думаю, что отсутствие удобочитаемости / ремонтопригодности EVER стоит того, что вы можете (или не можете) извлечь из него.
И заметка о WordPress: я много раз просматривал код WordPress. Не думайте, что эти люди знают что-нибудь о хорошем коде, пожалуйста.
Чтобы ответить на ваш первый вопрос, да, это правда, и это также верно для скомпилированного op-кода. Да, вы можете сделать свой код быстрее, избегая вызовов функций, за исключением случаев, когда ваш код становится слишком большим из-за дублирования кода.
Вы должны делать то, что вам нравится: «Мне нравится писать хорошо организованный, удобочитаемый код с помощью методов, где бы код кода повторялся».
Если вы собираетесь совершить это ужасное зверство при удалении всех вызовов функций, по крайней мере, используйте профилировщик и делайте это только с 10% вашего кода.
Пример того, как микро-оптимизация приводит к макроэкономическим замедлениям:
Если вы серьезно рассматриваете функции ручной установки вручную, подумайте о ручном разворачивании циклов.
JMP дорогостоящие, и если вы можете исключить циклы путем разворачивания, а также устранить все условные блоки, вы устраните все это время, потраченное только на поиск кэша процессора.
Увеличение переменной во время выполнения также слишком медленное, так как вытаскивает вещи из базы данных, поэтому вы должны также встроить все эти данные в свой код.
Фактически, загрузка переводчика для простого выполнения кода и копирования памяти пользователю является исчерпывающим, почему бы нам просто не предварительно вычислить все возможные страницы и сохранить каждую страницу в памяти, готовой к работе, так что это просто копия ? конечно, это быстро!
Ах, теперь у нас есть эта медленная вещь, называемая Интернетом между нами, что мешает работе с пользователями и ограничивает количество контента, которое мы можем использовать, как насчет предварительного расчета страниц заранее и архивирования их всех и запускать их на пользователей локальной машины? это будет очень быстро!
Но это будет тратить циклы процессора, многие из них, то, что с загрузкой страницы и отображением содержимого браузера и т. Д., Мы пропустим посредника и просто доставим страницы на них на печатные носители !. Genius !.
/ me наблюдает, как ваша компания рушится на лице, пока вы проводите предварительную компьютерную обработку (вручную) и печатные страницы, которые никто не хочет видеть.
Это может показаться вам глупым, но для всех нас то, что вы предложили, просто смешно.
Оптимизация хорошая, но нарисуйте линию где-то разумно, поэтому вам не нужно беспокоиться о будущих людях, которые работают над кодом, отслеживающим вас во сне, за то, что такая дрянная кодовая база не поддается.
Примечание: да, я использую gentoo. Как ты догадался?
Конечно, вы не должны писать плохой PHP-код. Но как только у вас что-то написано плохо, вы всегда можете использовать исполнение как оправдание 🙂
Это преждевременная оптимизация. Хотя утверждение верно, что вызов функции стоит больше, чем увеличение локальной целочисленной переменной (почти все стоит дороже), затраты на вызов функции по-прежнему очень низки по сравнению с запросом базы данных.
Смотрите также:
Википедия -> Оптимизация -> Когда оптимизировать
c2.com Wiki -> Преждевременная оптимизация
Основная сила PHP заключается в том, что быстро и легко получить рабочее приложение. Эта сила исходит из возможности написать свободный (плохой) код, и он все еще работает несколько ожидаемым образом.
Если вы в состоянии сохранить несколько циклов процессора, PHP не то, что вы должны использовать. Когда веб-приложения PHP работают плохо, это гораздо более вероятно из-за неэффективных запросов, а не от скорости выполнения кода.
Если вы так беспокоитесь по поводу эффективности, то почему вы используете скриптовый язык? Вы должны программировать на гораздо более быстром языке (вставьте свой любимый скомпилированный язык здесь), возможно, в результате получится более и менее читаемый код, но он будет работать очень быстро, и вы все равно можете стремиться к лучшим методам кодирования.
Серьезно, если вы кодируете скорость работы, вы не должны использовать PHP вообще.
Если вы разрабатываете веб-приложения с архитектурным шаблоном MVC, вы можете значительно выиграть от кеширования и сериализации. Вы можете кэшировать представления или их части, и вы можете сериализовать модели.
Из опыта модели часто анализируют и генерируют большую часть данных, которые отображаются. Если вы знаете, что определенная модель не будет генерировать новые данные часто, например, модель, которая анализирует RSS-канал, вы можете просто добавить ее где-нибудь со всеми проанализированными данными и обновить ее каждый раз.
Если вы посмотрите на PHP-код WordPress, он смешивает теги php между своим html, что приводит к спагетти в моем сознании.
Тем не менее, Phpbb3 лучше подходит в этом отношении. Например, он имеет строгое разделение между частью php и частью стилей, которые являются файлами в формате xhtml с тегами {template}, анализируемыми движком шаблонов. Это намного чище.
Напишите пару 10-минутных примеров и запустите их в своем профилировщике.
Это скажет вам, что быстрее на миллисекунду.
Если у вас нет профилировщика, разместите их здесь, и я запустил их в своем профилировщике PHPEd.
Я подозреваю, что большая часть разницы во времени, если таковая имеется, возникает из-за того, что нужно открыть файл, в котором хранится класс, но это тоже нужно проверить.
Затем спросите себя, не заботитесь ли вы о нескольких миллисекундах, а также о необходимости сохранять код спагетти – кто-нибудь из ваших пользователей когда-нибудь заметит?
редактировать
Профилировщик не будет имитировать большие объемы трафика, но он скажет вам, какой метод выполняется быстрее для одного пользователя, и какие части кода используют сколько времени. Особенно, если вы просматриваете операции, выполняемые повторно, – скажем 1000 раз в каждом цикле.
Мы можем предположить (хотя и не всегда), что более быстрый код, используемый многими людьми, будет быстрее, чем более медленный код, используемый многими людьми.
Те, кто прочитает вам о микро-оптимизации кода, как правило, будут теми же, у которых будет 50 запросов SQL на страницу, заняв в общей сложности 2 секунды, потому что они никогда не слышали о профилировании. Но их код оптимизирован !!! (и медленно, как ад)
Факт: добавление другого веб-сервера не сложно. Репликация базы данных. Оптимизация кода веб-сервера может быть чистым убытком, если он добавляет нагрузку на БД.
Примечание: 2-3 мс для простых страниц (например, тема форума), включая SQL, является хорошей мишенью для веб-сайта PHP. Мой старый сайт использовал это.