Несколько фишек в PHP

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

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

Итак, поехали:

1. file_get_contents() - очень крутая штука.

   Многие используют довольно правильно file_get_contents() и знают, для чего эта функция используется, но не многие в документации по PHP дочитали до того, что "Использование функции file_get_contents() наиболее предпочтительно в случае необходимости получить содержимое файла целиком, поскольку для улучшения производительности функция использует технику отображения файла в память (memory mapping), если она поддерживается вашей операционной системой", благодаря чему:

   simplexml_load_string( file_get_contents ('file.xml') )

   работает быстрее, чем:

   simplexml_load_file('file.xml')

   но давайте не будем на этот пример обращать внимания, так как с XML в наше время редко кто работает. А обратимся сразу к следующему примеру: Если вы разбираете файл с "\n" разделителями (или к примеру CSV, TSV, или нечто подобное), советую заменить file() на

   explode(PHP_EOL, file_get_contents('file.xml'));

   Здесь прирост в скорости обработки будет еще больше, чем в случае с xml. Видимо, file() — не очень удачно реализована.

2. count() или sizeof() - есть разница, хотя на самом деле обе функции дают одинаковый результат, но sizeof() меньше нагружает систему. Его меньше используют только потому что функция count() есть во многих других языках и ее легче запомнить и, соответственно, использовать при переходе между платформами
3. JSON или XML - однозначно, JSON - убийца XML. Его обработка идет на 20%-30% быстрее, чем обработка аналогичных структур данных на XML. Дополнительно замечу, что json_decode() быстрее работает без второго аргумента (генерируя объект, а не массив), но незначительно.
4. file_exists() и include() - проверять file_exists() затем делать include(), дешевле, чем проверять возврат include(), если вы, к примеру, не уверены, что файл на месте.
5. isset() и empty() - многие путают эти функции. empty() - проверяет переменную на пустоту и не выдаёт предупреждения, если даже переменная не определена, то есть она совмещает в себе функцию isset(). А что такое пустота для PHP? В PHP пустота это 0, "", array(), 0.0, FALSE, Null или переменная без значения.

   isset() - проверяет только две вещи: объявлена ли переменная и не является ли она NULL!

   Получается, что код:

   $name = '';
   if( isset($name) ) echo "Hello {$name}\n";
   if( !empty($name) ) echo "Hello {$name}\n";

   выведет нам совершенно разные вещи.

   А если использовать isset() при генерации SQL запросов, то вообще можно в запрос передать пустое значение:

   $params['alias'] = $_GET['alias'];
   ...
   // сбор sql запроса, для PHP переменная $params['alias'] всё же объявлена, НО ПУСТАЯ!
   if(isset($params['alias'])) $where[] = 'alias = "'.addslashes($params['alias']).'"';

   Поэтому думайте, где и когда использовать isset(), а где empty().

6. Static vars - статическая переменная класса, самое лучшее место для быстрого получения глобальных данных, замечен прирост в 5 — 10 раз.
7. Быстрый PHP код содержит минимум PHP - этот совет подойдет многим разработчикам на интерпретируемых языках. В PHP содержится огромное количество нативных (написанных на Си) функций. Их скорость превышает любой аналог на PHP. Поэтому старайтесь использовать именно их. И плавно переходим к пункту 8.
8. Перечитывайте phpmanual команда разработчиков PHP реализовала огромное количество функционала, который можно использовать. Большая его часть описана в официальной документации, которая постоянно обновляется. Освежайте свои знания, приумножайте их, регулярно пересматривая мануал. Как минимум надо знать все php.ini настройки и то, на что они влияют.
9. Не используйте оператор "@" - оператор @, используемый для скрытия ошибок при выполнении определенной инструкции плох по двум причинами: во-первых он медленный, а во-вторых привыкание к нему нежелательно, потому как при использовании его к вызовам функций, вы автоматически заблокируете возникновение ошибок в вызываемой функции, что может быть нежелательным. Часто оператор @ используется при доступе к ассоциативному массиву в тех случаях, когда нет уверенности в существовании того или иного ключа. В этом случае можно обойтись такой конструкцией:

   $x = isset($arr['x'])? $arr['x']: null;

   Это противоречит пункту 7, но у каждого правила могут быть исключения!
10. Работайте в режиме E_ALL | E_NOTICE | E_STRICT - именно в такой режим следует выставить error_reporting если вы начинаете работать над проектом. NOTICE - это то, что часто игнорируют и в то же время то, что чаще всего содержит ошибки. Если вы обратились к неопределенной переменной или к массиву по несуществующему ключу, то возникнет NOTICE. Допускать их, это ужасно, да. Но если ваш junior developer, не хочет признавать их важность, расскажите ему, что на генерацию одного NOTICE у PHP уходит время, за которое можно обойти и обработать массив примерно из 30-ти элементов. Если вы не уверены в существовании переменной/ключа в массиве, следует проверять с помощью оператора isset() ( пункт 5 ).
11. Развивайтесь - читайте чужой код, читайте код тех инструментов, которые вы используйте. Читайте код фреймворков, на которых разрабатываете. Это очень интересно и полезно. Также вы узнаете, что пишут этот код не боги, а такие же программисты как и вы. А если будете внимательными, то обнаружите массу неоптимальных моментов или ошибок.

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