Path Profiling интересен как теоретическая проблема.gprof также интересно, потому что он имеет дело с графами вызовов, циклическими подграфами и тому подобным.Есть хорошие алгоритмы для манипулирования этой информацией и распространения измерений по всей структуре.
Все это может заставить вас думать, что это работает (хотя они никогда не говорят, что это работает) - для поиска общих проблем производительности.
Однако предположим, что ваша программа зависает.Как вы находите проблему?
Что я делаю, это включаю ее в бесконечный цикл, а затем прерываю (пауза), чтобы посмотреть, что он делает.Я смотрю на код на каждом уровне стека вызовов, потому что я знаю, что цикл находится где-то в стеке.Если это не очевидно, я просто шагаю вперед, пока не увижу, что это повторяется, и тогда я знаю, в чем проблема.Я подозреваю, что почти каждый мог бы сделать это.
На самом деле, если вы остановите программу, пока она занимает слишком много времени, и несколько раз исследуете ее состояние, вы сможете найти не только бесконечные циклы, но и практически любую проблему, когда программа запускается.дольше, чем хотелось бы.
Существуют инструменты профилирования, основанные на этой концепции, такие как Zoom и LTProf , но за мои деньги ничто не дает столь же глубокого понимания, как тщательнопонимание репрезентативных снимков.
Вы не найдете хороших ссылок на эту технику, потому что (как ни странно) не многие знают о ней, и ее слишком просто опубликовать.
Там значительнобольше на эту тему.
На самом деле, FWIW, я «опубликовал» статью об этом, но она была рецензирована только редактором, и я не думаю, что кто-то действительно читалit: Dunlavey, «Настройка производительности с учетом затрат на уровне команд, полученных из выборки из стека вызовов», Уведомления ACM SIGPLAN 42, 8 (август 2007 г.), стр. 4-8.