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

Ответ 1

Акула, один из инструментов профилирования в Mac OS X, может сделать это (или даже профиль по инструкции). Я понимаю, что ваш скриншот находится в Windows, поэтому может быть не очень полезно, но, возможно, вы можете запустить свой код на Mac. Вы можете попробовать Very Sleepy, но я никогда не использовал его, поэтому не знаю, насколько он хорош.

Ответ 2

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

$ 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:}

Ответ 3

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

Ответ 4

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

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

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

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

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

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

Ответ 5

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