Выполняют ли все профилиляторы медленное выполнение?

Question

Профилировщики, с которыми я сталкиваюсь (в основном, с профилировщиком Digital Mars D, который приходит с компилятором), значительно замедляют выполнение профилируемой программы. Это сильно влияет на мою готовность использовать профилировщик, поскольку он делает профилирование «реального» запуска многих моих программ, в отличие от тестирования на очень небольшом входе, непрактичным. Я не очень разбираюсь в том, как применяются профилировщики. Является ли серьезное (> 2x) замедление при профилировании в значительной степени факта жизни, или есть профилировщики, которые его избегают? Если этого можно избежать, есть ли какие-либо быстрые профилировщики для D, предпочтительнее для D2 и, желательно, бесплатно?

Answer 1

Я не знаю о D-профиляторах, но в целом есть два разных способа, которыми профилировщик может собирать информацию для профилирования.

Первый - с помощью инструментария, путем инъекции протоколов вызовов по всему месту. Это замедляет приложение более или менее. Как правило, больше.

Вторая выборка. Затем профилировщик прерывает приложение через регулярные промежутки времени и проверяет стек вызовов. Это совсем не замедляет работу приложения.

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

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

Answer 2

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

Answer 3

Вы можете попробовать h3r3tic's xfProf, который является профилировщиком пробоотбора. Не пробовал сам, но этот парень всегда делает интересные вещи :)

Из описания:

Если программа оцифровывается только несколько сотен (или тысяч) раз в секунду, производительность накладные расходы не будут заметны.

Answer 4

My favorite method of profiling замедляет программу путь путь вниз, и это нормально. Я запускаю программу под отладчиком с реалистичной загрузкой, а затем вручную ее прерываю. Затем я копирую стек вызовов где-то, как в Блокнот. Таким образом, для сбора одного образца требуется порядка минут. Затем я могу либо возобновить выполнение, либо даже нормально начать его с самого начала, чтобы получить еще один образец.

Я делаю это 10 или 20 раз, достаточно долго, чтобы увидеть, что программа действительно делает с точки зрения стены. Когда я вижу что-то, что появляется много, я беру больше образцов, пока он не появится снова. Затем я останавливаюсь и действительно изучите, что он находится в процессе работы и почему, что может занять 10 минут или больше. Вот как я узнаю, что эта деятельность - это то, что я могу заменить более эффективным кодом, т. Е. Это было не обязательно.

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

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

Если вы хотите усмехаться менеджером, просто сделайте это один или два раза.

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