На прошлой неделе я прочитал пост, рекомендованный мне в PHP Weekly. Он назывался Микрооптимизация в PHP. Я повелся, ведь всегда стремлюсь быть лучшим PHP разработчиком. Пост начинается с общих рекомендаций, которые, по сути, являются даже не микро-, а микро-микрооптимизацией. Продолжая читать, я приходил к выводу, что описанное в тексте и вовсе имеет мало общего с оптимизацией. В итоге я могу сказать, что пост был написан безответственно — заявления автора не имели обоснований.
Обидно, что я получаю такие низкокачественные посты из рассылки PHP. Подобные статьи путают разработчиков, что, в свою очередь, способствует созданию некачественных приложений в сообществе PHP-разработчиков. Эта ситуация заставляет задуматься о росте числа хейтеров PHP.
Я не сомневаюсь в том, что автор писал статью с исключительно добрыми намерениями. Но, по крайней мере, он должен был предоставить доказательства сделанных в статье заявлений. В конце концов, хороший разработчик должен всегда спрашивать,почему? Я прочитал рекомендуемые в том посте оптимизации. Я оценил рекомендации с точки зренияабсолютной правды и обозначил каждую из них как истина или ложь. Пожалуйста, ознакомьтесь с полным текстом, прежде чем заметите ошибки.
foreach против for
Ложь.
foreach работает быстрее, если цикл используется для чтения массива. Если вам нужно записать что-то в массив, то foreach значительно ухудшит производительность. Здесь самое место циклу for.
Другой случай, когда лучше использовать for — блок, содержащий логику подсчета.
Смотрите сами:
for ($i = 0; …; ++$i) {
// block
}Для foreach эквивалентно:
$i = 0;
foreach (…) {
// block
++$i;
}Исключение: Если цикл используется в численно индексированном массиве, то ключ массива может служить счетчиком.
Истина.
Две абсолютные правды при использовании цикла for:
- Предварительно рассчитывайте части условия выражения. Условие в цикле for оценивается на каждой итерации. Избежание перезагрузок вызова функций, которые возвращают значение, не меняющееся в течение цикла, оптимизирует ваш код.
- Используйте преинкремент. По своей природе преинкремент быстрее.
Код:
$count = count($arr);
for ($i = 0; $i < $count; ++$i) {
// block
}
Двойные кавычки против одинарных
Ложь.
Еще в 2007 году Илья Альшанецкий сообщил мне по электронной почте о некоем Оптимизационном мифе. И все-таки это были времена PHP 4. Где-то в PHP 5 двойные кавычки были оптимизированы (я слышал о PHP 5.1).
То, что двойные кавычки работают быстрее, чем одинарные, ни чем не обосновано. Если в строке не используются переменные, само собой разумеется, что одинарные кавычки обрабатываются быстрее. Кроме того, буквенные значения (одинарные кавычки) могут быть оптимизированы в памяти.
Я протестировал двойные кавычки по отношению к одинарным несколько раз, так и не найдя убедительных доказательств. Может быть двойные кавычки действительно ускоряют процесс… Но, замена всех одинарных кавычек на двойные, что предлагается в оригинальной статье — это пустая трата времени. В конце концов, следование своему стилю кодирования является более важным.
UNION против OR
Ложь.
Я сейчас читаю книгу под названием Высокооптимизированный MySQL. На самом деле, я только что закончил главу, посвященную оптимизации запросов. Эта рекомендация фактически направила меня на путь написания ответного поста. Заявление автора, что надо заменить все ` OR ` на ` UNION ` просто безрассудно.
Во-первых, оригинальный пример плохой. Предлагается заменить следующее:
select username from users where company = ‘bbc’ or company = ‘itv’;на:
select username from users where company = ‘bbd’
union
select username from users where company = ‘itv’;При использовании одной и той же колонки, по заявлению автора, его решение более производительно. То есть вы должны заменить UNION на OR, причем WHERE продолжает работать на той же колонке.
Во-вторых, замена OR на UNION в запросах не может вернуть один и тот же результат. В то же время использование UNION может быть связано с оптимизацией, но вы должны понимать, когда использовать его. Не стремитесь заменить OR на UNION во всем коде.
Я все еще учусь MySQL-оптимизации, и отправил эту тему в сообщество StackOverflow. Я призываю вас прочитать
ответы для получения более подробной информации о том, почему противопоставление UNION и OR не всегда является оптимизацией.
Дополнительная PHP-оптимизация
В исходной статье было несколько верных советов по оптимизации:
- Используйте echo вместо print. Истина.
- Используйте строковые функции через регулярные выражения. Это спараведливо, за исключением сложного сопоставления с образцом. Эквивалентный регулярным выражениям код, написанный с использованием строковых функций, будет более производительным. Об этом говорится в PHP-документации для функции регулярных выражений.
Правило 80/20 в производительности
Производительность также подчиняется правилу 80/20. Если употребление одинарных кавычек превышает двойные на 80% — вы оптимизированы. Поздравляю. Вы можете идти домой.
Запомните
Серебряной пули не существует. Будьте скептиком абсолютной отчетности. Система имеет много нюансов. То, что работает для кого-то, может не работать для вас. Если в чем-то сомневаетесь, то лучше проверьте это сами.
Ссылки
Если вы заинтересованы в повышении производительности и оптимизации PHP, можете посетить следующие ресурсы:
Кроме того, почаще заглядывайте в документацию PHP. Там содержится ценная информация в виде описания функций и комментариев пользователей.