Про оптимизацию скорости php-скриптов
Забудьте все разговоры о том, что быстрее: foreach или for, одинарные кавычки или двойные.
Это все -- экономия на спичках.
Оптимизировать нужно только то, что реально тормозит.
1. используй дебаггер типа xdebug, xhprof для оценки поведения скрипта и его отдельных частей.
в крайнем случае можно использовать временные метки на основе microtime
2. если нет под рукой дебаггера, но что-то сильно тормозит, то метод деления пополам поможет.
определяем начальную и конечную точку выполнения скрипта, замеряем время выполнения.
ставим метку посередине скрипта, сравниваем.
если верхняя половина работает быстро, то проблема в нижней части, дальше ее тоже делим пополам и т.д.
в итоге найдем либо функцию, либо тупой алгоритм.
функцию дебажим так же, алгоритм переписываем.
3. читай мануал на предмет полезных функций
например, для обхода массива в 10 тысяч элементов и простого действия над каждым элементом лучше воспользоваться, при возможности, функциями array_walk или array_map, чем крутить foreach. это не панацея, но иногда помогает.
4. очень часто причиной тормозов становится тупой и неоптимизированный sql-запрос.
не стоит, например, считать количество записей в таблице, делая select * from table и считая количество возвращаемых записей.
5. не стоит в цикле делать 1000 запросов к базе, т.к. наверняка существует способ запросить данные только один раз.
6. кешеры байткода типа eaccelerator, apc, xcache помогут сократить время исполнения если тормоза из-за большого количества файлов.
Это тот необходимый минимум, который покрывает 90% задач по оптимизации быстродействия.
Это все -- экономия на спичках.
Оптимизировать нужно только то, что реально тормозит.
1. используй дебаггер типа xdebug, xhprof для оценки поведения скрипта и его отдельных частей.
в крайнем случае можно использовать временные метки на основе microtime
2. если нет под рукой дебаггера, но что-то сильно тормозит, то метод деления пополам поможет.
определяем начальную и конечную точку выполнения скрипта, замеряем время выполнения.
ставим метку посередине скрипта, сравниваем.
если верхняя половина работает быстро, то проблема в нижней части, дальше ее тоже делим пополам и т.д.
в итоге найдем либо функцию, либо тупой алгоритм.
функцию дебажим так же, алгоритм переписываем.
3. читай мануал на предмет полезных функций
например, для обхода массива в 10 тысяч элементов и простого действия над каждым элементом лучше воспользоваться, при возможности, функциями array_walk или array_map, чем крутить foreach. это не панацея, но иногда помогает.
4. очень часто причиной тормозов становится тупой и неоптимизированный sql-запрос.
не стоит, например, считать количество записей в таблице, делая select * from table и считая количество возвращаемых записей.
5. не стоит в цикле делать 1000 запросов к базе, т.к. наверняка существует способ запросить данные только один раз.
6. кешеры байткода типа eaccelerator, apc, xcache помогут сократить время исполнения если тормоза из-за большого количества файлов.
Это тот необходимый минимум, который покрывает 90% задач по оптимизации быстродействия.