Как найти медленные функции после инлайна?

Сделай отдельный профиль компиляции, в котором инлайниться ничего не будет, и профилируй бинарники из него обычным профилировщиками.

Можно это как-то обойти?

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

Здрасте. Толку тогда? Мне нужно тестировать производительность с инлайном, а не до.

Я не очень понял, если Вы хотите замер производительности заинлайниной ф-ии, то наверное Вы хотите просто узнать время работы соотв.фрагмента кода?

Насколько сильная разница будет между таким замером для инлайн-фрагмента и для тела той же функции?

Так тебе нужно тестировать производительность, или найти медленные функции?

Разница после inline огромна.

Это разные вещи?

Это для всего кода, а для тела функции?

Во-первых gprof, там можно даже line-by-line profiling делать https://sourceware.org/binutils/docs/gprof/Line_002dby_002dline.html

Во-вторых есть вот такая штука https://gcc.gnu.org/onlinedocs/gcc/Instrumentation-Options.html

-finstrument-functions - можно специальную функцию вызывать на каждый вызов какой-либо функции, и таким образом можно померять.

void __cyg_profile_func_enter (void *this_fn,
                               void *call_site);
void __cyg_profile_func_exit  (void *this_fn,
                               void *call_site);

Еще есть проприетарный Vtune от Intel и опенсорсный CodeXL от AMD но я ими не пользовался.

Разверните мысль.

Разница во времени работы кода с инлайном и без инлайна огромна. Теперь берем какую то функцию

void f(){
   double t0 = omp_get_wtime();
   ...
   double t1 = omp_get_wtime();   
}

насколько сильно будут различаться t1-t0 в случае если f() заинлайнена и если нет?

Время считать бессмысленно. Там нули будут.

Ок, а если гипотетически?

Я согласен с provaton, поиск узкого места и замер общей производительности это разные задачи.

Инлайн очевидно влияет на общую производительность, но не факт что он в процентном отношении сильно меняет вклад отдельных функций.

Вам то что именно нужно, найти узкое место в коде или точно замерить сколько времени занимает какая то функция?

проприетарный Vtune от Intel

я пользовался, убрал все лимиты на инлайн и числодробилка стала процентов на 5 быстрее. но профилирование при этом вылетает в трубу, vtune показывает одну гигантскую функцию, что в целом логично.

Ну gcc не вариант, ибо rust.

CodeXL не осилил собрать. Он использует scons и ему походу нужен python2. Какие-то левые ошибки сыпет. Завтра попробую снова.

Мне нужно понять какой кусок асма тупит, и потом найти какая функция его породила.

PS: CodeXL - типичный корпоративный комбайн:

2.7 GiB (2,941,504,224)
17,657 files, 2,821 sub-folders

И это только сорцы.

perf?

Ну gcc не вариант, ибо rust.

https://github.com/rust-lang/rust/pull/57220

А найти какая функция тормозит без инлайна это не вариант? Скорее всего она и тормознутый кусок асма порождает?

Насколько сильная разница будет между таким замером для инлайн-фрагмента и для тела той же функции?

Меньше, чем плата за использование профилировщика

Да, я кстати никогда не юзал valgrind в таком качестве. Насколько он как профилировщик тормозит? Потому что когда память им чекаешь это адский ад…

не знаю, но очевидно, что добавление кода, который что-то замеряет/логгирует - это больший оверхед, чем несколько инструкций вызова функции и ее заголовка с футером

Уже интереснее. Спасибо.

Так valgrind не модифицирует бинарь.

Судя по наблюдениям, инлайн позволяет очень сильно перекроить код, из-за чего данные собранные до инлайна становятся бесполезными.

Но прям для самой функции? Чот сомнительно.

Э… я конечно не знаю что у Вас за задача, и на расте никогда не писал, но все же (идеологически) данные по неинлайновым функциям ИМНО вполне релевантны для поиска узких мест.

Более того, при инлайне и оптимизации код может быть изуродован как Богом черепаха, и вопрос «сколько уходит на выполнение инлайн функции» может быть просто лишен смысла - там может оказаться несколько функций в перемешку (я не специалист, могу ошибаться).

Обычно, при профилировании числодробилок, больше всего помогает даже не профилировщик а общие замеры производительности и здравый смысл. Но числодробилки относительно простые…

Да. Добавление директивы inline может давать 20-30% прирост.

И в рантайме тоже? Как же он тогда меряет?

Без понятия.

Мне казалось он крутит код на какой то вирт. машине?

Дебажная информация включена при сборке?

Мне кажется, что ты хочешь невозможного. Профилировщик и инлайнинг - вещи сильно несовместимые. Есть только один инструмент, который поможет тебе решить задачу - это твоя собственная голова.

Да, и вообще, на мой взгляд роль профилировщиков в оптимизации приложения немного преувеличена. Профилировщики - это не манна небесная. Они все искажают информацию. Даже могут увести в сторону. Повторюсь, здесь больше головой надо думать.

Может быть и наоборот. У меня был случай, когда одна функция вызывалась овер миллион раз, тк ее нужно было к каждому элементу массива применить. Сделал передачу массива в функцию (вместо элемента) и вуаля - разница в несколько десятков процентов по производительности.

Смотря какая. Имена функций видны, но отладочной инфы нет.

Там в соседней теме аноним советует perf annotate, который очень похож на то, что я хочу. Но он увы не работает.

UPD: оно таки работает, но не нужно указывать путь к бинарю, как в инструкции.

В общем ничего проще и удобнее чем отключить глобально inline и прогнать прогу через valgrind в Qt Creator так и не нашлось.

Расскажете потом насколько это помогло в поиске узких мест после инлайна?

Дык я и до этого этот метод использовал. Так что никак. Для меня основная польза valgrind - это счётчик вызовов функций. Ну и call graph.

А cachegring?

Perf?

Никогда его не использовал.

Я не знаю как в расте, но в c++ флаг -g позволяет увидеть заинлайненные функции в бэктрейсах

Да, эта инфа хранится. Но у меня тот же perf annotate у 99% ассемблерных команд пишет 0. Так что толку от него мало. А часто используемые функции я и без валгринда знаю.

AMD CodeXL (бесплатно), Intel Vtune (за много денег).

Но у меня тот же perf annotate у 99% ассемблерных команд пишет 0. Так что толку от него мало. А часто используемые функции я и без валгринда знаю.

Смешались в кучу кони, люди… perf и callgrind - совсем разные инструменты. callgrind показывает количество инструкций в каждой выполненной функции, что позволяет получить более-менее воспроизводимые результаты между запусками. Да и аннотации к сорсам он тоже умеет.

Это понятно. Я к тому, что что так, что эдак - всё равно не то.

Возможно, боттлнек просто не там где ты ищешь, а у тех функций, на которые ты смотришь, вклад действительно около нуля