Если я правильно понял изначальный вопрос и посоветованные решения, то call-graph можно и быстро «на коленке» замутить → https://github.com/dim13/pvtrace
У «профайлера для С» такая проблема, что, будучи неаккуратно применённым, он неисправимо испортит собственно те тайминги, которые ты пытаешься с его помощью намерить. Потому что затраты процессорного времени на работу профайлера вполне могут превысить таковые на основную задачу. Поэтому «просто запустил» в любом случае не прокатит, надо думать ещё уметь.
а какой минимум функциональности в нем должен быть?
что понимается под «инструментальный», т.к. какое-то размытое понятие в отличии от того же семплинга.
Я так понимаю есть желание вкорячить сбор статистики для целей профилирования прямо в кодовую базу в дебажную сборку? Если да, то смысл? Отдельно стоящие профилировочные инструменты делают это лучше и нагляднее и умеют в разнообразный выхлоп который проще и нагляднее понимать и предоставлять для понимания другим.
чем просто ручной враппер над дельтой времени + возможно как выше предложили построение графа вызовов не это минимальное решение?
Ну и + любая нормальная иде у себя под капотом имеет уже какие-то инструменты для профилирования, они тоже не подходят как бескровное решение?
а так gprof, hpctoolkit, последний более гуишный и визуальный. Но они нельзя сказать чтобы маленькие, в виду того, что умеют намного больше чем наколенное поделье.
Прикольно, спасибо, это почти оно, только не считает времена выполнения, зато много секса с символами, а иногда хочется и в пределах одной функции разные точки посмотреть.
Минимум - статистика времён выполнения для каждой уникальной цепочки вызовов, без учёта мест которые заведомо портят статистику а для замера не интересны (т.к. с ними ничего низзя поделать например уже, например ввод/вывод).
Может это как-то можно и сэмплерным провернуть, но сэмплерный при всей простоте его использования, не даёт возможности спускаться ниже уровня отдельных функций без, хм, инструментирования :)
Инструментирование бывает ручное - ты прям руками в коде расставляешь точки инструментации(как например в lttng), и автоматическое, примерно как делает gprof(всякие finstrument-function) и gcov(не разбирался как работает, но т.к. абсолютно все условия инструментированы, не верю, что быстро).
Я так понимаю есть желание вкорячить сбор статистики для целей профилирования прямо в кодовую базу в дебажную сборку?
Нет, в релизную. Считать хочется единицы микросекунд и сотни наносекунд. То, что в ide даже в разрешении своём обычно имеет миллисекунды, если обращал внимание. perf с повышенной частотой даёт картинку и по таким величинам, но все измерения автоматом в попугаях получаются, и могут возникать забавные ситуации когда с перфом так быстрее, а без него эдак.
Я пока только локально-самописное видел, понятно, что с ограничениями разумными по количеству замеров и вот это(но оно для плюсов, и похоже мертво, хотя максимально похоже на правду, и можно было бы и к нему тупо сишный интерфейс приделать наверн).
Есть ещё lttng, но оно онтопик онли, хотя может уже и пофик…
Минимум - статистика времён выполнения для каждой уникальной цепочки вызовов, без учёта мест которые заведомо портят статистику а для замера не интересны (т.к. с ними ничего низзя поделать например уже, например ввод/вывод).