Используя gprof с сокетами
У меня есть программа, которую я хочу представить с gprof. Проблема (по-видимому) состоит в том, что это использует сокеты. Таким образом, я получаю вещи как это:
::select(): Interrupted system call
Я поразил эту проблему некоторое время назад, сдался и шел дальше. Но я действительно хотел бы смочь представить свой код, с помощью gprof, если это возможно. Что я могу сделать? Существует ли gprof опция, которую я пропускаю? Опция сокета? Действительно ли gprof полностью бесполезен в присутствии этих типов системных вызовов? Если так, есть ли жизнеспособная альтернатива?
Править: Платформа:
- Linux 2.6 (x64)
- GCC 4.4.1
- gprof 2.19
2 ответа
Код сокета должен обрабатывать прерванные системные вызовы независимо от профилировщика, но в профилировщике это неизбежно. Это означает наличие кода вроде.
if ( errno == EINTR ) { ...
после каждого системного вызова.
Взгляните, например, на здесь для фона.
gprof ( вот статья ) надежен, но он когда-либо предназначался только для измерения изменений , и даже для этого он измеряет только проблемы, связанные с процессором. Он никогда не рекламировался как полезный для обнаружения проблем . Это идея, которую другие люди наложили поверх нее.
Рассмотрим этот метод .
Еще один хороший вариант, если вы не против потратить немного денег, - это Zoom .
Добавлено: Если можно, приведу пример. Предположим, у вас есть иерархия вызовов, в которой Main вызывает A некоторое количество раз, A вызывает B некоторое количество раз, B вызывает C некоторое количество раз, а C ждет некоторого ввода-вывода с сокетом или файлом, и это в основном все программа делает. Теперь предположим, что количество раз, которое каждая подпрограмма вызывает следующую, на 25% больше, чем это действительно необходимо. Поскольку 1,25 ^ 3 примерно равно 2, это означает, что выполнение всей программы занимает в два раза больше времени, чем это действительно необходимо.
Во-первых, поскольку все время тратится на ожидание ввода-вывода, gprof ничего не скажет вам о том, как это время было потрачено, потому что он смотрит только на время «выполнения».
Во-вторых, предположим (просто в качестве аргумента) он подсчитал время ввода-вывода. Это может дать вам график звонков, в основном говоря, что каждая процедура занимает 100% времени. О чем тебе это говорит? Ничего больше, чем вы уже знаете.
Однако, если вы возьмете небольшое количество образцов стека, вы увидите на каждой из них строки кода, в которых каждая процедура вызывает следующую.Другими словами, это не просто дает вам приблизительную оценку времени в процентах, это указывает вам на конкретные строки кода, которые являются дорогостоящими . Вы можете просмотреть каждую строчку кода и спросить, есть ли способ сделать это реже. Предполагая, что вы это сделаете, вы получите ускорение в 2 раза.
Таким образом, люди получают важные факторы. По моему опыту, количество уровней вызова может легко достигать 30 и более. Каждый звонок кажется необходимым, пока вы не спросите, можно ли его избежать. Даже небольшое количество вызовов, которых можно избежать, может иметь огромное влияние на такое количество уровней.