Нужен performance analyzer

intel vtune это не то?

На каждую строчку хз, а так вообще OProfile и valgrind --tool=callgrind

gprof?

ещё strace иногда рулит

ну рулить-то он рулит, только в другую сторону:)

я о том что он умеет профилировать и периодически его проще пользовать чем другие профилировщики...

> ну рулить-то он рулит, только в другую сторону:)

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

intel vtune

Компилируешь с опцией -pg

gcc source.c -pg -o proga

Запускаешь прогу, потом запускаешь gprof

gprof -b ./proga

Получится файл, в котором будет выведено процентное соотношение выполнения разных функций. Это первый шаг поиска источника снижения производительности.

Потом компилируешь программу с опциями -fprofile-arcs и -ftest-coverage

gcc source.c -fprofile-arcs -ftest-coverage -o proga

Запускаешь прогу, потом запускаешь gcov

gcov ./proga

Получишь файл, в котором напротив каждой строчки исходника количество её исполнений. Смотришь сразу функции, нийденный на первом шаге.

Это был второй шаг. А вот дальше тебе не поможет никто...

gprof бывает полезен в довольно редких случаях: обычно сложно пересобрать все нужные библиотеки. valgrind несколько более юзабельный инструмент.

Если отлаживается код, который занимается какими-то вычислиниями, то этого достаточно.

А вот если есть системные вызовы, или, хуже того, какая-нибудь межнитевая синхронизация, то vtune - наше все.

Еще существует Rational Quantify, но собственного опыта его использования у меня нет.

> Компилируешь с опцией -pg

> gcc source.c -pg -o proga

> Запускаешь прогу, потом запускаешь gprof

Сложно представить нетривиальную программу с bottleneck'ом, работающую без тредов. С которыми не умеет работать gprof.

>ложно представить нетривиальную программу с bottleneck'ом, работающую без тредов.

напрмер если нада *быстрая* реакция на некоторые события.

для ядер 2.4 "быстрая" это <50ms

для 2.6 - не оценивал

>А вот если есть системные вызовы, или, хуже того, какая-нибудь межнитевая синхронизация

насколько я понимаю что если с нитками нарвались на bottleneck то скорее всего надо не профилировать а выпрямлять руки дизайнеру архитектуры...

> то скорее всего надо не профилировать а выпрямлять руки дизайнеру архитектуры...

Надо думать, что ядро и библиотеки непогрешимы по своей сути и не могут содержать каких-либо ошибок.

Я имею в виду, что большая программа, для которой может потребоваться анализ производительности, на вряд ли будет работать в одном потоке. Конечно, это не исключено, "случаи разные бывают", но маловероятно.

Ну как сказать. Они содержат массу нюансов мешающих выжать нужную производительность тривиальным образом. особенно если критично быстроджействие...

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

>Я имею в виду, что большая программа, для которой может потребоваться анализ производительности, на вряд ли будет работать в одном потоке.

X-сервера к примеру вполне сносно обходятся без ниток.