Поиск узких мест в приложении
У меня есть приложение .NET, и оно быстро проходит около 2000 записей, которые действительно начинают работать медленный. Я' я пытаюсь найти узкое место, и мне было интересно, есть ли хороший, возможно бесплатный, но это не обязательно должен быть инструмент или способ найти узкое место. Я пытаюсь найти список, который еще не очищен, но пока не вижу. У меня VS 2008.
4 ответа
Вы можете запустить несколько счетчиков производительности , чтобы отслеживать использование ЦП и статистику памяти и выяснять, что происходит.
Если это не приведет вас к каким-либо очевидным ответам, пора приступить к профилированию.
JetBrains dotTrace имеет 30-дневную бесплатную пробную версию. Это довольно приличный профилировщик памяти и производительности, который вы, возможно, захотите проверить.
Microsoft CLR Profiler бесплатен.
Если вы все еще ничего не придумали, пора бросить серьезный удар: WinDbg . Если вы зайдете так далеко, вы найдете блог Тесс чрезвычайно полезным.
Есть очень хороший бесплатный инструмент, и он у вас уже есть. Единственный недостаток заключается в том, что он может быть не интуитивным с самого начала.
Если программа работает медленно, приостановите ее в среде IDE. Изучите стек вызовов. (Я выключаю отображение аргументов; меня интересуют только определенные строки кода. Я копирую весь стек в текстовый редактор, например в блокнот.) Сделайте это несколько раз. Чем он медленнее, тем меньше образцов вам понадобится, прежде чем вы обнаружите проблему.
Если вы видите одно или несколько утверждений, которые подозрительно популярны, например, они встречаются в значительной части образцов (как минимум, двух), вам следует обратить на них внимание. Что я делаю, так это беру еще несколько образцов, пока они не появятся, потому что я хочу понять, почему они выполняются. Это важно, потому что, если бы я мог заменить их чем-то, что занимало бы намного меньше времени, я бы сэкономил большую часть.
Попробую объяснить, почему это работает. Во-первых, широко распространенное понятие «узкое место» вводит в заблуждение. Программное обеспечение не медленное, потому что у него есть ограничения или «горячие» места. Конечно, могут быть промахи в кеше и т. Д., Но основная причина он медленный, потому что делает больше, чем нужно - часто на много больше.
Срабатывает при джанкетах вызовов вложенных функций, с оправданиями все более отдаленными. Это выглядит как дерево вызовов, которое намного более густое, чем необходимо.Все, что вам нужно сделать, это найти большие ветки, которые можно обрезать. Вот что делает техника паузы.
Итак, пока вы рыетесь в поисках инструмента, который поможет вам в роли детектива найти неуловимое "узкое место", станьте хирургом-деревом и подрежьте самые тяжелые ветви дерева вызовов, найденные путем паузы и продолжай делать это, пока не сможешь.
Скептицизм - это хорошо, но вы можете быть удивлены, насколько хорошо это работает.
DevPartner for C++ my MicroFocus (ранее Compuware) имеет профилировщик производительности, который был наполовину приличным. Intel делает V-Tune, который делает то же самое. (Я думаю, что это Intel... Я никогда не использовал его). Мой любимый — тот, который поставляется с Visual Studio Team Edition. Это великолепно. Вы также должны инструментировать свой собственный код и писать автоматические тесты, чтобы вы могли сравнивать одну сборку с другой.
Эта страница от Адама Кальдерона содержит ссылки на некоторые страницы блога MSDN по профилированию.
Однако большинство (если не все) из них посвящены Visual Studio Team System. Поэтому, если у вас есть доступ к этой версии программного обеспечения, вы получаете некоторые инструменты «бесплатно».