агрегирование вызовов функций из данных профилирования WPR/xperf, например. KCacheGrind?

Можно ли загрузить данные профилирования WPR/xperf в KCacheGrind? Или есть способ агрегировать вызовы функций в WPA напрямую? Или какой-то другой инструмент? Будет ли маршрут gprof2dot/graphviz лучшим вариантом?

Я нахожу WPA полезным, но группировка по стеку в таблице «Использование ЦП (выборка)», похоже, не позволяет сортировать по агрегированному количеству вызовов функций. Например, если функция foo вызывается одинаково из 10 разных мест, будет сложно идентифицировать foo как потенциальное узкое место, поскольку каждый из 10 кодовых путей к foo будет иметь 10% или меньше веса. KCacheGrind решает эту проблему, позволяя выполнять сортировку по совокупному времени для каждой функции.

Как я могу сортировать по совокупному времени, затраченному на каждую функцию с профилированием в Windows, например. определить общие функции низкого уровня, такие как malloc, как узкое место?


person JDiMatteo    schedule 24.10.2014    source источник
comment
Кстати, почему я не вижу ни одной ссылки на malloc в своих данных WPA? Когда я делаю случайную паузу в Visual Studio, я вижу множество стеков вызовов, оканчивающихся на msvcr100.dll!malloc(). Есть ли параметр в WPR, который мне нужно отметить, чтобы получить этот уровень детализации?   -  person JDiMatteo    schedule 24.10.2014
comment
Не ищите конкретную функцию. Вместо этого возьмите образцы стека и посмотрите, какие на них строки кода. Это делает профилировщик Zoom с сайта rotateright.com, но я и многие люди считают, что ручной метод работает лучше. Пожалуйста, взгляните на это.   -  person Mike Dunlavey    schedule 25.10.2014
comment
@MikeDunlavey: спасибо, у меня уже был этот вопрос с вашим ответом в избранном :). Тем не менее, кажется, что мнение основано на том, является ли ручной метод или инструменты профилирования правильным, и я лично считаю, что комбинация лучше всего, поэтому, если кто-нибудь знает, как заставить этот инструмент WPR предоставлять полезную агрегированную информацию, я был бы признателен. Это. Кстати, Zoom не работает в Windows.   -  person JDiMatteo    schedule 27.10.2014
comment
Я полагаю, что это похоже только на мнение - программисты не привыкли к осторожным аргументам. Эта ссылка показывает, что ускорение может быть пропущено серверными частями профилировщика (ложноотрицательные результаты). Эта ссылка показывает, почему вам нужно игнорировать ложные отрицательные значения. Этот ответ содержит конкретный пример и ссылки на код. На шести этапах было сокращено более 99,8% времени, но любой пропущенный этап дорого обходится. Это не единичный пример. Этот пример и эти аргументы реальны, а не мнение.   -  person Mike Dunlavey    schedule 27.10.2014
comment
@MikeDunlavey: спасибо за это резюме. Вы убедили меня сейчас. Я перестану тратить время на профилировщики и просто буду использовать отладчики, случайные паузы и, возможно, время от времени регистрировать операторы.   -  person JDiMatteo    schedule 28.10.2014
comment
Я не хочу проповедовать. Это просто математика и эксперименты. Вы можете убедиться сами.   -  person Mike Dunlavey    schedule 28.10.2014