задался целью написать профайлер для собственных нужд. На PHP. В "Алгоритмы" разместил тему, потому как имею вопросы общего характера. Итак, профайлер. По моей задумке, счётчики должны составлять древовидную структуру. Т.е. если у меня код:

Сначала создаётся/обрабатывается счётчик с именем function1 для обработки времени работы вызова функции function1. А потом внутри  вызванной функции запускается ещё один счётчик. Мне охота, чтоб счётчики и хранились в виде дерева(вложенные массивы разной размерности). А вот теперь вопрос. Насколько такой подход рационален? Хотелось бы, естественно, свести к минимуму влияние вызовов функций профайлера на время работы программы. Или хотя бы учитывать "утерянное" время, но относящееся к тестируемой программе. Вижу два варианта решения:
1. Храним список "утерянного времени": при обращении к функции запуска нового счётчика засекается время начала работы этой функции и время выхода. А потом, при подсчёте статистики, эти промежутки учитываются и вычитаются из значений счётчиков. Недостаток налицо: дважды нагружаем своим классом процессор. И время выполнения скрипта вполне может выйти за интервал ограничения работы. Конечно, если я сам на своей машине тестирую, то я могу изменить время выполнения скрипта. Но если я захочу протестировать "вживую"?
2. Хранить список команд-обращений к профайлеру "как есть" - то есть в массиве в виде элементов ("тип команды", "время обращения") - вести что-то вроде лога запросов("запустить таймер "ВасяПупкин" ; 12:03:05" // "запустить подтаймер в "ВасяПупкин" с именем "ТожеВася"; 12:03:07" // "остановить таймер..."), а считать статистику непосредственно перед выводом, считая, что на запись этого "лога" времени не уходило вовсе. Тут недостаток - большой расход памяти. Особенно, если я управляю счётчиками в цикле. Да и опять же - обработка лога на основе ветвлений по типу команды может настолько нагрузить вычислениями сервер, что я не уложусь в 30/45/60 секундный интервал. 
Может, у кого есть лучшее решение(учитывая тупость/прямолинейность моих вариантов, лучшее решение просто обязано быть!)  
Спасибо за то, что дочитали до этого места и за конструктивную и даже Неконструктивную критику 

Добавлено @ 19:50 

Я это видел.   Потому про PHP можно было не говорить - интересуют решения в общем виде.