Как создать отчет о профиле графического кода для кода C ++, скомпилированного с помощью Clang LLVM? - PullRequest
Новая
       42

Как создать отчет о профиле графического кода для кода C ++, скомпилированного с помощью Clang LLVM?

2 голосов
/ 25 марта 2020

Как создать отчет о графическом профиле кода для кода C ++, скомпилированного с Clang LLVM?

  • Какие параметры командной строки я передаю в clang ++, чтобы дать ему команду собирать данные профилирования, когда код выполняется?

  • В каком файле (ах) хранятся собранные данные профилирования?

  • Каковы этапы последующей обработки для преобразовать собранные данные профиля в графический отчет, который показывает, как часто вызывается каждая функция, какой процент времени затрачивается на каждую функцию и из каких функций вызывается каждая функция (аналогично https://s3-us-west-2.amazonaws.com/brunorijsman-public/example-rift-python-code-profile.png)?

У меня есть полный контроль над исходным кодом C ++ и Makefile.

Это должен быть LLVM clang ++ (GNU g ++ не подходит для меня). Xcode также не вариант для меня.

Ответы [ 2 ]

1 голос
/ 03 апреля 2020

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

Какие параметры командной строки я передаю в clang ++, чтобы дать ему команду собирать данные профилирования при коде

  • Для покрытия исходного кода: в соответствии с llvm-cov , правильные флаги для сбора данных профилирования при -fprofile-instr-generate -fcoverage-mapping при компиляции и -fprofile-instr-generate при связывании.
  • Для вывода, совместимого с gcov: -fprofile-arcs -ftest-coverage

В каком файле (ах) хранятся собранные данные профилирования?

  • Для покрытия исходного кода: после запуска программы, скомпилированной и связанной с указанными выше флагами, данные покрытия сохраняются в default.profraw в вашем текущем рабочем каталоге. Имя файла данных профилирования можно изменить, перекомпилировав с помощью -fprofile-instr-generate=filename или установив переменную среды LLVM_PROFILE_FILE перед запуском исполняемого файла.
  • Для вывода, совместимого с gcov: после запуска программы вы получите *.gcda и *.gcno файлов.

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

  • Для покрытия исходного кода:

    1. Индексировать файл .profraw в файл .profdata: llvm-profdata merge -o default.profdata -sparse=true default.profraw
    2. Либо используйте llvm-cov show --instr-profile default.profdata ./your_program для просмотра покрытия в терминале, либо используйте llvm-cov export ./your_program --instr-profile default.profdata > out.json для преобразования данных профилирования в JSON и найдите / создайте программу для создания отчета для вас.

  • Для gcov-совместимого вывода:

    1. Используйте lcov или gcovr для генерации HTML вывода. Это позволяет легко просматривать покрытие линий и ветвей для каждого файла. Я склонен использовать gcovr, так как он просто pip install gcovr, если у вас его не установлено. Тогда использование будет gcovr --gcov-executable "llvm-cov gcov" -r . --html --html-details -o out.html.

и из каких функций вызывается каждая функция (аналогично https://s3-us-west-2.amazonaws.com/brunorijsman-public/example-rift-python-code-profile.png)?

Для такого типа информации я бы попытался взглянуть на Callgrind и KCacheGrind . Я не нашел ни одного инструмента, который мог бы генерировать информацию такого типа из файлов *.profdata или *.gcda.

0 голосов
/ 03 апреля 2020

Как уже упоминалось, gprof - это один инструмент профилирования, который вы можете использовать. Однако есть проблема, он только подсчитывает время процессора, он в основном не может видеть вызовы ввода / вывода. Это также смущает рекурсия. Callgrind также имеет аналогичные проблемы, KCacheGrind использует Valgrind, который фактически интерпретирует весь код. В конце концов, однако, эти варианты, лично, для малого масштаба я бы go с gprof просто из-за его удобства и документации.

...