Несколько других советов для PHP-разработчиков

Навеяно вот этим.

Я решил вспомнить некоторые особенности PHP, связанные с производительностью.

Отмечу, что включил в свой небольшой список лишь то, что обычно вызывает удивление у junior developers, с которыми мне приходилось работать.
О банальных вещах, вроде «одинарные кавычки вместо двойных», думаю, знают все, поэтому постараюсь кого-нибудь удивить.

Результаты и выводы, сделаны на основании нескольких версий PHP, который крутятся на знакомых мне серверах, а именно 5.2.6 из Debian Lenny, 5.3.2 из Ubuntu, и 5.2.14 из dotdeb. Возможно, на других платформах, есть отличия.

• file_get_contents
  Не секрет, что file_get_contents, использует (memory mapping), прирост от которого, особенно заметен на крупных файлах.
  Следствие этого:
  simplexml_load_string( file_get_contents ('file.xml') )
  работает быстрее, чем:
  simplexml_load_file('file.xml')
  Похоже, что подобные simplexml_load_file функции, базируются на обычных fopen/fread, что приводит к разнице в скорости.
  
  NB: Также неплохо ускоряется DOM->loadFile, и некоторые другие функции с похожим поведением.
  
  Если вы разбираете файл с \n разделителями (или к примеру CSV, TSV, или нечто подобное), советую заменить file() на
  explode(PHP_EOL, file_get_contents('file.xml'));
  Спасибо за подсказку c PHP_EOL LoneCat
  Прирост будет еще больше, чем в случае с xml.
  Видимо, file() — не очень удачно реализована.
  
• count() и sizeof()
  UPD: sizeof() это синоним count(), работает быстрее, спасибо merkushin за поправку.
  
• Notices, etc.
  Допускать нотисы, это ужасно, да.
  Но если ваш junior developer, не хочет признавать их важность, расскажите ему, что на генерацию одного notice у PHP уходит время, за которое можно обойти и инкрементировать массив из примерно 30-ти элементов.
  
• foreach
  Цикл foreach, практически в каждой статье, посвящённой производительности PHP, предают анафеме.
  На практике, не всё так страшно. Жуткие конструкции, вроде:
  while (list($key, $value) = each($item))
  в реальных условиях, часто бывают медленнее.
  Если же пропустить $key, то эта конструкция проигрывает foreach примерно 30-40%.
  
• JSON vs XML
  Скажу лишь, что перейдя на json-файлы для конфигурации, выиграл 20-30% на инициализации ядра. JSON приятен для глаз, иерархичен и быстр.
  Также, json_decode быстрее работает без второго аргумента (генерируя объект, а не массив), но незначительно.
  
• mb_ereg vs preg_match
  POSIX — выражения медленные, это опять же, общеизвестно.
  Но движок Oniguruma, который используется в функции mb_ereg, и её mb-собратьях, с этим не согласен, и примерно в двух третях случаев, обгоняет хвалёный preg_match.
  
• IGBinary для сериализации.
  Это очень быстрое расширение, с очень компактным значением на выходе.
  
• file_exists и include
  Проверять file_exists() затем делать include, дешевле, чем проверять возврат include(), если вы, к примеру, не уверены, что файл на месте.
  
• Опять include
  Не знаю почему, но include_once, часто проигрывает по скорости конструкции с принудительной проверкой (записываем в массив все включённые файлы).
  
• Static vars
  Статическая переменная класса, самое лучшее место для быстрого получения глобальных данных, замечен прирост в 5 — 10 раз.
  
• Напоследок, пара советов
  Показывайте себе время выполнения в миллисекундах, а не в долях секунды.
  Это здорово мотивирует (сравните, «100 миллисекунд» и «0.1 секунды»), и легче читается.
  Очень важно, собирать информацию, не только об абсолютной скорости, но и анализировать вклад отдельных подсистем: ядра, интерфейса данных, рендеринга, и.т.п.
  Свой профайлер, я настроил (на testing-машине) на выброс исключений, при аномальном замедлении каких-либо участков кода (пример: «Achtung! 30% времени на подключение к MySQL»).
  

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

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

Поэтому я осознанно не указывал абсолютных цифр, которые вы можете найти и сами, к примеру на http://phpbench.com/ (не моё)

Удачи и быстрого кода!