Серьезно, стоит ли писать плохой PHP-код?

Вы должны увидеть ответы на этот вопрос: Должен ли разработчик в первую очередь стремиться к удобочитаемости или производительности?

Подводя итог консенсусу: если вы не знаете наверняка (посредством тестирования / профилирования), что ваша производительность должна быть решена в какой-то конкретной области, удобочитаемость гораздо важнее.

Какая «эффективность» вам нужна? Ты хоть мерил? Преждевременная оптимизация - это корень всех зол, а оптимизация без измерения ВСЕГДА преждевременна.

Помните также правила Клуба Оптимизации.

1. Первое правило Клуба оптимизации: вы не оптимизируете.
2. Второе правило Optimization Club: вы не оптимизируете без измерения.
3. Если ваше приложение работает быстрее, чем основной транспортный протокол, оптимизация завершена.
4. Один фактор за раз.
5. Ни маркетроидов, ни графиков маркетроидов.
6. Тестирование будет продолжаться столько, сколько потребуется.
7. Если это ваша первая ночь в Optimization Club, вам нужно написать тестовый пример.

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

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

Лично, хотя могут возникнуть накладные расходы на вызов функции, если это означает, что я пишу код один раз (параметризованный), а затем использую его в 85 местах, я ПУТЬ впереди, потому что я могу исправить это в одном месте.

Языки сценариев, как правило, дают людям представление о том, что «достаточно хорошо» и «работает» - единственные критерии, которые следует учитывать при кодировании.

Конечно, не стоит писать плохой PHP-код. Но если у вас что-то написано плохо, вы всегда можете использовать производительность как оправдание :-)

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

Смотрите также:

Википедия -> Оптимизация -> Когда оптимизировать

c2.com Wiki -> Преждевременная оптимизация

Основная сила PHP в том, что быстро и легко получить работающее приложение. Эта сила заключается в возможности писать неаккуратный (плохой) код, при этом он по-прежнему работает несколько ожидаемым образом.

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

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

Вы должны делать то, что вам нравится: «Мне нравится писать хорошо организованный, удобочитаемый код с методами везде, где может повторяться блок кода».

Если вы собираетесь совершить это ужасное злодеяние, удалив все вызовы функций, по крайней мере, используйте профилировщик и сделайте это только с 10% вашего кода, который имеет значение.

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

Серьезно, если вы пишете код для скорости бега, вам вообще не следует использовать PHP.

Пример того, как микрооптимизация приводит к замедлению работы макросов:

Если вы серьезно рассматриваете возможность встраивания функций вручную, рассмотрите возможность развертывания циклов вручную.

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

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

Фактически, загрузка интерпретатора для простого выполнения кода и копирования памяти пользователю является чрезвычайно расточительной, почему бы нам просто не вычислить все возможные страницы и не сохранить каждую страницу в памяти, готовую к работе, так что это просто копия памяти ? конечно это быстро!

А, теперь между нами есть медленная штука, называемая Интернетом, которая мешает взаимодействию с пользователем и ограничивает количество контента, которое мы можем использовать, как насчет того, чтобы мы заранее вычислили страницы, заархивировали их все и запустили на пользователи локальная машина? это будет очень быстро!

Но это приведет к потере циклов процессора, их много, что, учитывая время загрузки страницы, рендеринг содержимого браузера и т. д., Мы пропустим посредника и просто доставим им страницы на печатных носителях! Гений !.

/ me наблюдает, как ваша компания разваливается на глазах, пока вы тратите 10 лет на предварительные вычисления (вручную) и печать страниц, которые никто не хочет видеть.

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

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

Примечание: да, я использую gentoo. как ты угадал?

Я думаю, Joomla и Wordpress - не лучшие примеры кода PHP хорошо, без обид. Я не имею ничего личного против людей, работающих над этим, и это здорово, как они позволяют людям иметь веб-сайт / блог, и я знаю, что многие люди тратят все свое свободное время на любой из этих проектов, но качество кода довольно низкое (с без обид).

Если вы мне не верите, просмотрите объявления о безопасности за последний год; также предполагая, что вы ищете производительность от любого из двух, их код также не преуспевает в этом. Так что это ни в коем случае не хороший код, но Wordpress и Joomla превосходны во внешнем интерфейсе - довольно просты в использовании, люди получают веб-сайт и могут выполнять вещи.

Вот почему они так успешны, что люди выбирают их не по качеству кода, а по тому, что они позволили им сделать.

Чтобы ответить на ваш вопрос о производительности, да, это правда, что все хорошие вещи (функции, классы и т. д.) Замедляют работу вашего приложения. Итак, я предполагаю, что если ваше приложение / сценарий все в одном файле, пусть будет так. Тогда не стесняйтесь писать плохой код PHP.

Как только вы расширите и начнете дублировать код, вам следует подумать о компромиссе (в скорости), который приносит с собой написание поддерживаемого кода. :-)

ИМХО, этот компромисс невелик по двум причинам:

1. CPU является дешевый.
2. Разработчики не недорого.

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

Вы можете делать все, что угодно, чтобы PHP работал быстрее. Обычно люди рекомендуют кеш, например БТР. APC действительно потрясающий. Он запускает для вас всевозможные оптимизации в фоновом режиме, например кэширует байт-код файла PHP, а также предоставляет вам функции в пользовательском пространстве для сохранения данных.

Так, например, если вы анализируете файл конфигурации каждый раз, когда запускаете этот скрипт, ввод-вывод диска действительно важен. С помощью простых apc_store () и apc_fetch () вы можете сохранить проанализированный файл конфигурации либо в файловом кэше, либо в кэше памяти (RAM) и извлекать его оттуда до тех пор, пока кеш не истечет или не будет удален.

Конечно, APC - не единственный кэш.

Особенно с быстрым интерпретатором, таким как PHP, я не думаю, что отсутствие читабельности / ремонтопригодности КОГДА-ЛИБО стоит той эффективности, которую вы можете (или не можете!) Получить от этого.

И примечание о WordPress: я много просматривал код WordPress. Не думайте, что эти люди что-то знают о хорошем коде, пожалуйста.

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

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

Если вы посмотрите на php-код wordpress, он смешивает теги php между своим html, что приводит к спагетти в моей голове.

Однако в этом отношении Phpbb3 намного лучше. Например, в нем есть строгое разделение между частью php и частью стилей, которые представляют собой файлы в формате xhtml с тегами {template}, анализируемые механизмом шаблонов. Что намного чище.

Напишите пару 10-минутных примеров и запустите их в профайлере.

Это скажет вам, что быстрее до миллисекунды.

Если у вас нет профилировщика, опубликуйте их здесь, и я запущу их в моем профилировщике PHPEd.

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

Затем спросите себя, заботитесь ли вы о нескольких миллисекундах по сравнению с необходимостью поддерживать спагетти-код - заметит ли кто-нибудь из ваших пользователей?

Редактировать

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

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

Те, кто будет читать вам лекции о микрооптимизации кода, обычно те же самые, у которых будет 50 SQL-запросов на страницу, что в сумме займет 2 секунды, потому что они никогда не слышали о профилировании. Но их код оптимизирован !!! (и чертовски медленно)

Факт: добавить еще один веб-сервер несложно. Репликация базы данных есть. Оптимизация кода веб-сервера может привести к чистым убыткам, если добавит нагрузку на БД.

Примечание. 2-3 мс для простых страниц (например, темы форума), включая SQL, - хорошая цель для веб-сайта PHP. Мой старый сайт раньше делал это.