Несколько советов для PHP-разработчиков
Результаты и выводы, сделаны на основании некоторого количества версий PHP, который крутятся на знакомых мне серверах, а именно 5.2.6 из Debian Lenny, 5.3.2 из Убунту, и 5.2.14 из dotdeb. Вероятно, на иных платформах, есть различия.
🕛 26.08.2010, 00:47
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("\n", file_get_contents('file.xml'));Прирост будет еще более, чем в случае с 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 скорее работает без II-го аргумента (генерируя объект, а не массив), однако незначительно.ereg vs preg_MATCHPOSIX - выражения медленные, это снова, общеизвестно. Однако движок Oniguruma, который применяется в функции mb_ereg, и её mb-собратьях, с этим не согласен, и приблизительно в 2-х третях случаев, обгоняет хвалёный preg_match.IGBINARY для сериализации.Это весьма быстрое расширение, с весьма компактным значением на выходе.file_exists и Includeпроверять file_exists() после делать include, дешевле, чем проверять возврат include(), если вы, например, не уверены, что файл на месте.Снова include Не знаю по какой причине, однако include_once, нередко проигрывает по скорости конструкции с принудительной проверкой (записываем в массив все включённые файлы).Static Varsстатическая переменная класса, самое лучшее место для быстрого приобретения обширных данных, замечен прирост в 5 - 10 раз.Напоследок, парочка Советовпоказывайте себе время исполнения в миллисекундах, а не в долях сек..Это здорово мотивирует (сравните, "100 миллисекунд" и ".1 сек."), и проще читается.Весьма важно, подбирать информацию, не только лишь об абсолютной скорости, но еще и анализировать вклад отдельных подсистем: ядра, интерфейса данных, рендеринга, и.т.п.Собственный профайлер, я настроил (на testing-машине) на выброс исключений, при аномальном замедлении любых участков кода (пример: "Achtung! 30% времени на подключение к MYSQL").
Все выводы получены, в итоге индивидуальных наблюдений и тестов.Весьма вероятно, что на вашей системе, результаты будут другие.