Я пытаюсь профилировать (с 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 белый, как снег 🙁 и говорит ноль инструкций …)
Правильно ли я использовал макросы / опции? Любая идея, что мне нужно изменить, чтобы получить ожидаемый результат?
Мне наконец удалось решить эту проблему … Это была проблема конфигурации:
Я сохранил код
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 итераций бенчмарк … неподходящий для регрессионного теста).
тумблер сбор Опция очень требовательна к тому, как вы указываете метод для использования в качестве триггера. Вам также нужно указать список аргументов, и даже пробел должен совпадать! Используйте имя метода точно так, как оно указано в выходных данных callgrind. Например, я использую этот вызов:
$ valgrind
--tool=callgrind
--collect-atstart=no
"--toggle-collect=ctrl_simulate(float, int)"./swaag
Пожалуйста, обратите внимание: