Профилирование C кодирует в Windows при использовании Eclipse

Существует MinGW-порт gprof, который работает примерно так же, как и Linux-вариант. Вы можете либо получить полную установку MinGW (я думаю, что gprof включен, но не уверен), либо получить gprof из пакета MinGW binutils.

Для Eclipse есть TPTP, но он не поддерживает профилирование C/C++, насколько я знаю.

Да, вы можете профилировать код с помощью Visual Studio

В чем причина профилирования? Вы хотите a) измерить время и получить график вызовов, или b) найти вещи, которые нужно изменить, чтобы сделать код быстрее? (Это не одно и то же.)

Если (б), то вы можете использовать этот трюк, используя кнопку Pause в Eclipse.

Добавлено: Возможно, это поможет передать некоторый опыт того, на что на самом деле похожи проблемы с производительностью, и где их можно ожидать. Вот несколько простых примеров:

• Вставная сортировка (порядок n^2), где сортируемые элементы являются строками, и сравниваются функцией сравнения строк. Где горячая точка? В функции сравнения строк. Где проблема? В сортировке, где вызывается string-compare. Если n=10, то это не проблема, но если n=1000, то внезапно это занимает много времени. Точка, где вызывается string-compare, "холодная", но именно в ней и кроется проблема. Небольшое количество образцов стека вызовов точно определяет ее.

• Приложение, загружающее плагины, запускается очень долго. Профилировщик говорит, что практически все в нем "холодное". Что-то, что измеряет время ввода-вывода, говорит, что почти все время занимает ввод-вывод, что похоже на то, что вы могли бы ожидать, так что это может показаться безнадежным. Но образцы стека показывают, что большой процент времени тратится на стек глубиной около 20 слоев в процессе чтения ресурсной части подключаемых dll с целью перевода строковых констант на местный язык. Исследуя дальше, вы обнаруживаете, что большинство переводимых строк не являются теми, которые действительно нуждаются в переводе. Они были введены "на всякий случай", чтобы их можно было перевести, и никогда не думали о том, что это может вызвать проблемы с производительностью. Устранение этой проблемы дает значительную экономию времени.

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