Существует ли профилировщик для C (gcc) для профилирования строк кода отдельно? [закрытый]

Вы можете использовать утилиту GNU GCOV для построчного профилирования. Пример выполнения из GCC Docs .

$ gcc -fprofile-arcs -ftest-coverage tmp.c
$ a.out
$ gcov tmp.c
  90.00% of 10 source lines executed in file tmp.c
  Creating tmp.c.gcov

Файл tmp.c.gcov содержит вывод типа:

     -:    0:Source:tmp.c
     -:    0:Graph:tmp.gcno
     -:    0:Data:tmp.gcda
     -:    0:Runs:1
     -:    0:Programs:1
     -:    1:#include <stdio.h>
     -:    2:
     -:    3:int main (void)
     1:    4:{
     1:    5:  int i, total;
     -:    6:
     1:    7:  total = 0;
     -:    8:
    11:    9:  for (i = 0; i < 10; i++)
    10:   10:    total += i;
     -:   11:
     1:   12:  if (total != 45)
 #####:   13:    printf ("Failure\n");
     -:   14:  else
     1:   15:    printf ("Success\n");
     1:   16:  return 0;
     -:   17:}

Я считаю, что callgrind делает это. Я знаю, что это количество циклов в строке, но я не уверен насчет «времени».

Проверьте эту ссылку и попробуйте этот метод .

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

Для этого существуют инструменты: один - RotateRight / Zoom , а другой - LTProf . Лично я клянусь полностью ручным методом.

За последние пару дней у нас возникла проблема с производительностью в некотором коде здесь. Ручным методом нашел один способ сэкономить 40%. Затем я нашел способ сэкономить 40% сверх этого, в результате чего общая экономия составила 64%. Это всего лишь один пример. Вот пример экономии более 97%.

Добавлено: Это имеет социальные последствия, которые могут ограничить потенциальное ускорение. Предположим, есть три проблемы. Проблема A (в вашем коде) занимает половину времени.Проблема B (в коде Джерри) занимает 1/4 времени, а проблема C (в вашем коде) занимает 1/8 времени. Когда вы сэмплируете, проблема A выскакивает на вас, и, поскольку это ваш код, вы исправляете ее, и теперь программа занимает половину исходного времени. Затем вы снова сэмплируете, и задача B (теперь 1/2) выскакивает на вас. Вы видите, что это в коде Джерри, поэтому вы должны объяснить это Джерри, стараясь не смущать его, и спросить, может ли он исправить это. Если он этого не сделает по какой-либо причине (например, это был его любимый код), то даже если вы исправите проблему C, время можно будет сократить только до 3/8 от исходного времени. Если он это исправит, вы можете исправить C и сократить время до 1/8 от исходного. Тогда может возникнуть другая проблема D (ваша): если вы ее исправите, время сократится до 1/16 от исходного времени, но если Джерри не исправит проблему B, вы не сможете добиться большего, чем 5/16. Вот почему социальное взаимодействие может быть абсолютно критическим в настройке производительности.

Единственная техника, которую я видел, которая работает (потому что она применялась ко мне), - это подавать информацию печальным извиняющимся тоном, как если бы это была ваша проблема, и настойчиво излагать информация. Извиняющийся тон рассеивает смущение, а настойчивость заставляет его думать об этом.

Наш инструмент SD C Profiler работает с исходным кодом GCC. Он обеспечивает профилирование базовых блоков, а не линий; это дает ту же точную информацию со значительно меньшими накладными расходами.