2009-08-31 5 views
4

Я запускаю профилировщик Visual Studio 2008 в сборке «RelDebug» моего приложения. Оптимизация включена, но вложение только умеренное, присутствуют кадры стека, и символы испускаются. Другими словами, RelDebug - это несколько оптимизированная сборка, которая может быть отлажена (хотя обычные ограничения в отношении об обследовании переменных применяются).Visual Studio 2008 Profiler - Instrumented производит странные результаты

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

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

Например, функция типа SetFont, состоящая только из 1 строки, назначающей высоту члену класса. Или «SetClipRect», который просто присваивает прямоугольник.

Конечно, я смотрю статистику «Эксклюзив» (т. Е. Минус дети).

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

Я понял, что проблема. Как Visual Studio 2008, так и профилировщики Visual Studio 2010 являются посредственными (чтобы выразить это вежливо). Я купил Intel C++ Studio, который поставляется с vTune Amplifier (профилировщик). Используя профилировщик Intel по тому же самому коду, я смог получить результаты профилирования, которые действительно имели смысл.

ответ

2

Вы говорите: «Конечно, вы смотрите на Эксклюзив». Посмотрите на инклюзивную статистику. Во всех, кроме простейших программ или алгоритмов, почти все время тратится на подпрограммы и функции, поэтому, если у вас есть проблемы с производительностью, скорее всего, это звонки, которые вы не знали, были часами.

Метод, который я полагаюсь на is this. Предполагая, что вы пытаетесь выяснить, что вы можете исправить, чтобы сделать код быстрее, он найдет его, не теряя времени с высокоточными статистическими данными о вещах, которые не являются проблемами.

+2

Я говорю о том, что функции, которые ни при каких обстоятельствах не должны приближаться к вершине, появляются наверху. Это похоже на ошибку в профилировщике Instrumented. Профилировщик Sampling дает более точные результаты, которые имеют смысл. Я уже оптимизировал большую часть того, что можно оптимизировать без внесения алгоритмических изменений (мое приложение мухи). Я хочу использовать инструментальный профилировщик, чтобы выяснить, что заставляет мое приложение замедляться при использовании OpenMP и отладчика (без приложения отладчика, приложение не замедляется), но неверный результат из профилировщика Instrumented попадает в путь. –

+1

@TheVinn: Если вы считаете, что выиграть не так много, может быть, нет, и, возможно, есть: http: // stackoverflow.com/questions/926266/performance-optimization-strategy-of-last-resort/927773 # 927773 IMHO 1) не имеет значения, замедляет ли ваша техника «профилирования» приложение, если оно точно указывает на утверждения что стоило бы вам больше всего, потому что, когда вы их исправляете и прекратите диагностировать, скорость вернется, и 2) приборы могут рассказать вам, в лучшем случае, сколько% времени каждая процедура находится в стеке (и это его точная стоимость). Сэмплирование стека ... –

+1

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

1

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

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

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

+0

На самом деле SetFont - это моя функция, и она просто копирует небольшую легкую структуру. Его не называют очень много раз. И это не всегда одна и та же функция, часто рутина меняется. Его никогда не является рутиной, которая имеет смысл (т. Е. Одна из моих функций рабочей лошади), всегда всегда что-то почти не связанное с профилем производительности. –

+0

Вот пример, где ничто из этого не помогает. Предположим, что у вас есть главный вызов B, вызывающий C, вызывающий ... вызывающий Z, который на самом деле выполняет какую-то полезную работу, которая состоит из ввода-вывода файлов, поэтому время процессора пренебрежимо мало. Исключительное время процессора во всех подпрограммах незначительно. Предположим теперь, где B называет C, это просто вызывает его дважды, один раз необходимым образом и один раз ненужным образом. Время настенных часов удваивается. Система настолько велика, что вы не представляете, сколько раз каждая функция должна быть вызвана или как долго они должны принимать. ПК-пробоотборник бесполезен. –

+0

... Инструментарий бесполезен. Граф вызовов не говорит ничего другого, чем раньше. Однако, если вы просто приостанавливаете его несколько раз и каждый раз проверяете стек, в половине случаев вы увидите, что вызов (а не функция, _call_) на C не нужен. Вот как вы узнаете, что исправить, и сколько он сэкономит. Это может показаться надуманным, но в моем многолетнем опыте он репрезентативен. –