Настройка профилировщика в xdebug и средства анализа результатов его работы

xdebug.profiler_enable=1 - включает безусловное профилирование всех скриптов
xdebug.profiler_enable_trigger = 1 - включает условное профилирование скрипта (по наличию GET/POST-параметра XDEBUG_PROFILE
xdebug.profiler_output_dir - устанавливает путь сохранения результатов профилирования (cachegrind-файлов)
xdebug.profiler_append=1 - включает добавление результатов профилировки в предыдущий файл вместо создания нового
xdebug.profiler_output_name - задает формат имени профайл-лога. Можно использовать:
%p – идентификатор процесса
%r – случайное число
%u - время
%H – значение $_SERVER['HTTP_HOST']
%R – значение $_SERVER['REQUEST_URI']
%s – имя, включающее полный путь, слеши конвертируются в знаки подчеркивания

xdebug.profiler_enable (да я подозреваю, что и xdebug.profiler_enable_trigger) нельзя изменять с помощью ini_set(), видимо потому, что решение о включении профилировщика принимается до начала разбора скрипта. Это относится и к xdebug.profiler_output_dir.

Анализировать созданные профайл-логи можно с помощью:

- webgrind. Графиков и прочих красивостей не рисует, но выдает самую главную ифнормацию: число вызовов функций и их собственную / полную стоимость вызова (собственная не включает вызовы других функций в теле данной). По-умолчанию в меню сверху выводятся все профайл-логи xdebug из директории /tmp. Если xdebug настроен на сохранение логов в другой папке, необхоимо перенастроить webgrind (в файле config.php в папке устновки webgrind изменить значение статической перменной $profilerDir). Про установку webgrid в Debian я писал здесь: http://barbitoff.blogspot.com/2011/06/webgrind.html. Имхо не самый функциональный и удобный инструмент, да и к тому же, если включено безусловное профилирование, то webgrind, работающий на том же сервере, будет вызывать профилирование самого себя.. А условная профилировка не всегда удобна для AJAX-приложений, не будешь же добавлять XDEBUG_PROFILE во все AJAX-вызовы. В принципе, можно было бы отключить безусловную профилировку в глобальном php.ini, но включать её через ini_set() в тех php-файлах, которые хотим профилировать, но которым не хотим каждый раз передавать в GET/POST параметр XDEBUG_PROFILE (или наоборот, включить глобальную безусловную профилировку, а в index.php webgrind`а её выключить через ini_set()), но параметры xdebug.profiler_enable_trigger и xdebug.profiler_enable нельзя менять через ini_set(). Впрочем, эти параметры все ещё можно устанавливать через .htaccess, так что запрет профилирования webgrind`a сделать не сложно (не забыв, правда, в конфиге апача для директории webgrind установить AllowOverride Options):

php_value xdebug.profiler_enable 0


- kcachegrind. Самый, пожалуй, полнофункциональный инструмент, его и рекомендую. Имеет широкие возможности визуализации результата профилировки в виде рисования графов и карт вызовов. Вот пример его работы на очень простеньком скрипте:

Работает под Linux, но, говорят, возможен запуск и под Win, сам не пробовал. Всё, что необходимо сделать для анализа профайл-лога - открыть этот файл через меню.

- Wincachegrind. Как следует из названия, работает под Win, сам с ней не работал, но вроде бы она уже давно не разрабатывается и по функционалу уступает kcachegrind.

Полезная презентация про профилирование php-кода (и, в частности, про настройку профилирования в xdebug), есть тут: https://docs.google.com/viewer?a=v&pid=explorer&chrome=true&srcid=0BwZjamEZKA1CZTcxNDY4YzItMjc1ZS00ZjMyLWI2ODktNGI2YzkzZWZlZmRh&hl=ru&authkey=COraveAL