#profiling #valgrind #callgrind #kcachegrind
Вопрос:
Я профилировал некоторый код, который, вероятно, тратит много времени на выполнение в системных вызовах. Синхронизация некоторых функций вручную и с помощью callgrind, callgrind сообщает, что время системных вызовов примерно в 20, 30 или 40 раз больше, чем просто синхронизация функции (что, конечно, также включает время процессора).
—collect-systime=ON использовался для сбора этого времени системного вызова для каждой функции.
Насколько я знаю, callgrind работает путем подсчета инструкций процессора, а для синхронизации системных вызовов просто позволяет ОС выполнять работу и не вмешивается. Я не понимаю, почему время, затрачиваемое на системные вызовы, увеличивается при профилировании с помощью callgrind, может ли кто-нибудь уточнить?
Является ли callgrind по-прежнему полезным инструментом для профилирования времени, проведенного в системных вызовах?
Ответ №1:
Можете ли вы попробовать --collect-systime=usec и --collect-systime=nsec посмотреть, существенно ли они отличаются? usec может быть, немного быстрее.
Когда указано —collect-systime, Valgrind будет вызывать один из различных системных вызовов времени для каждого из системных вызовов клиентского приложения. Я ожидал бы, что это добавит существенные накладные расходы, особенно если ваше клиентское приложение вызывает очень много «быстрых» системных вызовов.
Комментарии:
1. Это объясняет, почему существует несоответствие, что очень ценно. Значения usec и nsec не работают в моем valgrind, он принимает только » да » или «нет», вероятно, проблема с управлением версиями. Однако теперь я ожидаю, что эти накладные расходы будут пропорциональны «sysCount», что очень полезно. Спасибо!
2. Обратите также внимание, что помимо накладных расходов, используемых callgrind из-за системных вызовов времени, само ядро valgrind добавляет значительные накладные расходы ко всем системным вызовам, например, ему приходится выполнять некоторые системные вызовы sigprocmask до и/или после «реального» системного вызова приложения.