2009-10-05 3 views
4

Кто-нибудь использует профилировщик .NET, сделанный вашим киком? Я ищу хороший профилировщик .NET и наткнулся на yourkit. Поскольку я куплю лицензию на одного человека, для меня это будет стоить 79 евро, что довольно хорошо imho. Мне также нравится: более или менее простой и удобный графический интерфейс.мнений о профилировщике yourkit .NET?

Но я не очень опытен в профилировании .NET-приложений, поэтому мне интересно, выполнит ли ваш профилировщик mykit .NET. Однако, похоже, в мире Java довольно хорошо известно, что Yourkit.

Любые мнения?

+1

Eqatec - бесплатный профайлер .Net (http://www.eqatec.com/tools/profiler), если стоимость является проблемой. Никогда не пробовал, хотя, так что не могу прокомментировать, насколько это хорошо. – adrianbanks

+0

Я дал короткую попытку, но профайлер yourkit кажется более удобным для работы. Я не против платить за программное обеспечение, однако, вероятно, лучший профилировщик (как прочитанный в Stackoverflow) от redgate слишком дорог для меня. Так что менее 100 евро будет в порядке. – Max

+0

Лучшим профайлером для .net на сегодняшний день является F1, который находится в командной системе Visual Studio. Я использовал redgate экстенсивно и нашел его в основном бесполезным для профилирования любых трудных проблем. Отсутствие информации о ядре о таких вещах, как контекст и переключатели потоков, затрудняет работу со сложными многопоточными приложениями. –

ответ

1

Мнение? Да. Пока вы решаете, какой профилировщик купить или нет, give this a try.

ADDED: @Max: Пошаговые инструкции. В IDE есть кнопка «пауза». Запустите приложение в среде IDE, и пока оно субъективно медленно, то есть пока вы его ждёте, нажмите кнопку «пауза». Затем получите снимок стека вызовов.

Чтобы сделать снимок стека вызовов, то, что я делаю, отображает его (это одно из окон отладки). В параметрах IDE вы можете найти параметры для отображения в представлении стека. Я отключу опцию для отображения аргументов функции, потому что это делает строки слишком длинными. Меня интересует номер строки, где происходит вызов, и имя вызываемой функции. Затем в представлении стека вызовов вы можете сделать «Выбрать все», а затем «Копировать», а затем вставить его в «Блокнот». Я знаю, это немного неуклюжий, но я записывал их вручную.

Я беру несколько образцов таким образом. Затем я смотрю на них для строк, которые появляются на более чем одном образце, потому что это время. Некоторые из них просто необходимы, как «называть главное», но некоторые из них не являются. Это золотые самородки. Если я их не найду, я продолжаю брать образцы, примерно до 20. Если я еще не найду (очень необычно), к тому времени программа довольно хорошо оптимизирована. (Ключевым моментом является то, что каждый раз, когда вы делаете это, программа становится быстрее, и при этом оставшиеся проблемы с производительностью становятся относительно большими & проще найти. Т.е. программа не только ускоряется с определенным отношением R, но и остальными проблемами побольше, в процентах, по тому же отношению.) *

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

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

* Предположим, что ваш код тратит 90% своего времени на выполнение X, и 9% его времени делают Y, оба не нужны. Возьмите небольшое количество образцов, и вы увидите X, но, вероятно, не Y. Если вы исправите X, вы получите 10-кратное ускорение. Повторите выборку (возможно, вам придется обернуть внешний цикл вокруг программы, чтобы вы могли брать образцы). Теперь вы видите Y с уверенностью, потому что теперь он принимает 9% x 10x = 90%. Фиксация дает вам еще 10x, для полного 100x ускорения.

+0

Кто-то дал мне проехать. Это свидетельствует о том, что это противоречиво. Вот еще одно объяснение: http://stackoverflow.com/questions/406760/whats-your-most-controversial-programming-opinion/1562802#1562802 –

+0

Ваш путь звучит интересно, но, честно говоря, я не совсем уверен, как это сделать используя C# и Visual Studio 2008 (словом: я еще не понял). Любая «пошаговая» инструкция по этому поводу? – Max

+0

@Max: Я ответил выше. –

0

Отказ от ответственности: мое предложение основано на предположении, что вы серьезно относитесь к профилированию производительности и хотели бы узнать точное улучшение вашей настройки.

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

Проблема с профилировщиками общего назначения заключается в том, что они добавляют слишком много служебных данных и делают результат неточным. Но, тем не менее, они хорошо справляются с поиском тяжелых операций. Когда вы используете профилировщик и находите операцию, занимающую 40% от общего времени процесса, действительно ли она занимает 40%? Возможно, нет. Но для запуска, вероятно, требуется много времени.

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

PS. Я также предлагаю вам прочитать о performance profiling, который даст вам общее представление о концепции и поможет понять предложения других людей.

+0

@Bill: Я предлагаю серьезно относиться к улучшению производительности, не требует точного априорного измерения коэффициента усиления, которого можно достичь, поскольку он может быть точно измерен апостериорным. Также не важно, что метод оказывает минимальное влияние на производительность (свидетель ValGrind). Важно то, что он * быстро и точно определяет * проблемы. Профилисты еще этого не делают (хотя могли). –

+0

@Mike: Я согласен с тем, что важно быстро найти проблему. Но я как бы проиграл ваш априорный/апостериорный аргумент, вы имеете в виду, что улучшение производительности - это апостериорное знание, а не априорное знание? В этом случае я согласен, и это то, что я предлагаю. –

+0

@Bill: Например, предположим, что есть команда вызова функции, которая находится в стеке ровно в 50% случаев (так что это именно то, что она стоит). Предположим, вы взяли 5 выборок случайных стеков. Вы могли видеть это на 0 образцах (очень маловероятно), 1 образец (маловероятный) 2 образца (оценка 40%), 3 (оценка 60%), 4 (маловероятно) или 5 (очень маловероятно). Таким образом, вы точно знаете, где это, и исправление даст вам скидку до 50%, даже если вы заранее не знали, насколько это спасло бы вас. Это помогает? –