LINUX.ORG.RU

Профилирование кода


0

0

Хочу по завершении работы функции получать суммарное время, проведенное в запросах к БД и прочим внешним ресурсам и время, проведенное непосредственно в коде. Естественно, под временем я понимаю «реальное время в человеческих единицах вроде микросекунд».

Что кроме clock_gettime(CLOCK_MONOTONIC) можно использовать?

Ответ на: комментарий от mv

>gettimeofday

Календарные часы подвержены коррекциям всякого рода и для измерения интервалов времени ну никак не пригодны.

linuxfan ()
Ответ на: комментарий от linuxfan

Если под конкретную архитектуру, то можно time stamp counter читать. Правда, в smp-системе программку лучше бы к конкретному процессору через аффинити прибить.

mv ★★★★★ ()
Ответ на: комментарий от linuxfan

> Что кроме clock_gettime(CLOCK_MONOTONIC) можно использовать?

Календарные часы подвержены коррекциям всякого рода и для измерения интервалов времени ну никак не пригодны.

Сколько пафоса %) А ничего, что clock_gettime меряет реальное время, а не затраченное на исполнение программы?

tailgunner ★★★★★ ()
Ответ на: комментарий от tailgunner

А ничего, что clock_gettime меряет реальное время, а не затраченное на исполнение программы?

Да его в системе с вытесняющей многозадачностью точно и не измеришь в принципе.

Топик стартер: если ядро свежее (>.30, лучше 32), то там появились perf_counters (переименованы в event_counters), можешь ещё с ними помучаться.

mv ★★★★★ ()
Ответ на: комментарий от mv

> Да его в системе с вытесняющей многозадачностью точно и не измеришь в принципе.

Есть виртуальный таймер, специально предназначенный для профилирования. Вам что, маны цитировать? %) Есть oprofile, наконец.

tailgunner ★★★★★ ()
Ответ на: комментарий от tailgunner

Есть виртуальный таймер, специально предназначенный для профилирования. Вам что, маны цитировать? %) Есть oprofile, наконец.

Время на переключение контекста как учитывается? Из того, что я вижу, никак не учитывается. Поэтому в случае с частым переключение данные будут некорректными.

mv ★★★★★ ()
Ответ на: комментарий от mv

>> Есть виртуальный таймер, специально предназначенный для профилирования. Вам что, маны цитировать? %) Есть oprofile, наконец.

Время на переключение контекста как учитывается?

Как время, проведенное в ядре, IIRC.

Поэтому в случае с частым переключение данные будут некорректными.

Время в юзермоде будет корректным.

tailgunner ★★★★★ ()
Ответ на: комментарий от tailgunner

>Есть виртуальный таймер, специально предназначенный для профилирования.

Это о setitimer/getitimer? Они же сигналы генерируют. Стремно как-то.

linuxfan ()
Ответ на: комментарий от linuxfan

Ну, от ситуации зависит. Вообще, если профилируешь «для себя», и clock_gettime, и gettimeofday, и чтение TSC подходят ровно одинаково. Если пишешь встроенную систему профилирования, то всё сложнее - там придется использовать setitimer или getrusage.

tailgunner ★★★★★ ()
Ответ на: комментарий от anonymous

>> встроенную систему профилирования

Это как?

Ну, например, программа должна регулярно выдавать пользователю отчет о том, где сколько времени она потратила.

tailgunner ★★★★★ ()
Ответ на: комментарий от tailgunner

Как время, проведенное в ядре, IIRC.

Часть тактов всё равно теряется.

Время в юзермоде будет корректным.

Точность utime/stime - это до сих больной вопрос, даже с CFS.

mv ★★★★★ ()
Ответ на: комментарий от mv

> Точность utime/stime - это до сих больной вопрос, даже с CFS.

Вопрос в сравнительной точности их и gettimeofday. В присуствии переключений контекста, я выберу utime/stime. Хотя для одноразовой наколенной поделки это не имеет значения.

tailgunner ★★★★★ ()
Ответ на: комментарий от tailgunner

Вопрос в сравнительной точности их и gettimeofday. В присуствии переключений контекста, я выберу utime/stime.

Да это пофиг. Если utime пользовать без stime, то получится фиг знает что. Суммарно же они время более-менее точно дают, ибо берут время от того же источника, что и gettimeofday - из tsc.

mv ★★★★★ ()
Ответ на: комментарий от mv

> Если utime пользовать без stime, то получится фиг знает что.

Получится профилирование userspace-кода. Если возвращаться к топику, то получится время, затраченное программой, за вычетом времени на запросы к внешним ресурсам.

Суммарно же они время более-менее точно дают, ибо берут время от того же источника, что и gettimeofday - из tsc.

Ммм... вероятно, ты хотел сказать что-то другое %) Понятно, что источник времени единый.

tailgunner ★★★★★ ()
Ответ на: комментарий от tailgunner

Получится профилирование userspace-кода.

Не получится. runtime процесса считается в ns по tsc, а соотношение utime/stime - по тикам таймера. utime в /proc плюётся, как utime * ns, а stime, как (ns - utime * ns). Ну или наоборот, не помню. Соответственно, 10 jiffies в utime совершенно не говорит о том, что там реально не 500 было. Вместе говорят, ибо суммарно реальные ns получаются, а по отдельности - нет.

mv ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.