Callgrind: профиль определенной части моего кода

Я пытаюсь профилировать (с Callgrind) конкретную часть моего кода, удаляя шум и вычисления, которые меня не волнуют.
Вот пример того, что я хочу сделать:

for (int i=0; i<maxSample; ++i) {
//Prepare data to be processed...
//Method to be profiled with these data
//Post operation on the data
}

Мой вариант использования — это регрессионный тест, я хочу убедиться, что рассматриваемый метод все еще достаточно быстр (что-то вроде менее 10% дополнительных инструкций с момента последней реализации).
Вот почему я хотел бы иметь более чистый вывод из Callgrind.
(Мне нужен цикл for для обработки значительного объема данных, чтобы иметь хорошую оценку поведения метода, который я хочу профилировать)

Моей первой попыткой было изменить код на:

for (int i=0; i<maxSample; ++i) {
//Prepare data to be processed...
CALLGRIND_START_INSTRUMENTATION;
//Method to be profiled with these data
CALLGRIND_STOP_INSTRUMENTATION;
//Post operation on the data
}
CALLGRIND_DUMP_STATS;

Добавление макросов Callgrind для управления инструментами. Я также добавил опции —instr-atstart = no, чтобы быть уверенным, что я профилирую только ту часть кода, которую я хочу …

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

Я тоже пробовал

for (int i=0; i<maxSample; ++i) {
//Prepare data to be processed...
CALLGRIND_TOGGLE_COLLECT;
//Method to be profiled with these data
CALLGRIND_TOGGLE_COLLECT;
//Post operation on the data
}
CALLGRIND_DUMP_STATS;

(или опция —toggle-collect = «myMethod»)
Но Callgrind вернул мне журнал без каких-либо звонков (KCachegrind белый, как снег 🙁 и говорит ноль инструкций …)

Правильно ли я использовал макросы / опции? Любая идея, что мне нужно изменить, чтобы получить ожидаемый результат?

14

Решение

Мне наконец удалось решить эту проблему … Это была проблема конфигурации:

Я сохранил код

for (int i=0; i<maxSample; ++i) {
//Prepare data to be processed...
CALLGRIND_TOGGLE_COLLECT;
//Method to be profiled with these data
CALLGRIND_TOGGLE_COLLECT;
//Post operation on the data
}
CALLGRIND_DUMP_STATS;

Но управлял callgrind с —сбор-atstart = нет (и без —instr-atstart = нет !!!), и он работал отлично, в разумные сроки (~ 1 мин).

Проблема с инструментарием START / STOP заключалась в том, что callgrind создает дамп файла (callgrind.out. # Number) на каждой итерации (каждая STOP), таким образом, это было действительно очень медленно … (после 5 минут у меня было только 5000 запусков для 300 000 итераций бенчмарк … неподходящий для регрессионного теста).

12

Другие решения

тумблер сбор Опция очень требовательна к тому, как вы указываете метод для использования в качестве триггера. Вам также нужно указать список аргументов, и даже пробел должен совпадать! Используйте имя метода точно так, как оно указано в выходных данных callgrind. Например, я использую этот вызов:

$ valgrind
--tool=callgrind
--collect-atstart=no
"--toggle-collect=ctrl_simulate(float, int)"./swaag

Пожалуйста, обратите внимание:

  • Двойные кавычки вокруг опции.
  • Список аргументов, включая скобки.
  • Пробел после запятой.
1

По вопросам рекламы ammmcru@yandex.ru
Adblock
detector