Какие функции должен иметь профилировщик С#/. NET?

Это может быть пограничная реклама, не говоря уже о субъективном, но вопрос честный. За последние два месяца я разрабатывал новый профилировщик с открытым исходным кодом для .NET, называемый SlimTune Profiler (http://code.google.com/p/slimtune/).

Это относительно новое усилие, но когда я посмотрел на диапазон доступных профилировщиков, я не был впечатлен. Я сделал некоторую начальную работу на основе существующих продуктов, но я чувствовал, что это будет хорошее место, чтобы спросить: что именно вы хотите от профилировщика?

Я прихожу из графики в реальном времени и игр, поэтому для меня важно, чтобы профайлер был как можно быстрее. В противном случае игра становится неиграбельной и профилирование неиграбельной медленной игры имеет тенденцию не быть очень просвещенным. Я готов пожертвовать некоторой точностью в результате. Меня даже не волнуют исключения. Но я не очень хорошо разбираюсь в том, что интересует разработчиков для других типов приложений. Есть ли у вас какие-либо возможности для создания или разлома? Где упадут существующие инструменты?

Опять же, я прошу прощения, если это просто от базы для StackOverflow, но это всегда был невероятно полезный ресурс для меня, и здесь есть очень широкий спектр разработчиков.

Ответ 1

Мои требования:

Соберите статистику без воздействия на приложение - например. не заполняйте память, позволяйте собирать данные из приложений, находящихся под вопросом.
Возможность задания измерений просто и повторяемо (с управлением данными)
Автоматически, чтобы я мог повторять измерения без точек и кликов, и без интерфейса
Позвольте нам понять проблемы, связанные с WPF и другими декларативными технологиями, такими как DLR или WF
Нет установки - нет gac, msi и т.д., даже лучше, если их можно запустить через сеть.
Поддержка 64 бит с самого начала
Не пытайтесь знать весь анализ, который можно было бы сделать - поощрять экосистему. Если сырые статистики могут быть проанализированы с использованием других инструментов, тем лучше.
Пользовательский интерфейс, если он должен быть хорошим, - но его характеристики, которые имеют значение. Поэтому не тратьте время на это, получите хорошее профилирование.
- Профилирование профилей приложений, которые не являются просто бесплатными сервисами и веб-приложениями.

понравится:

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

Ответ 2

Мой список пожеланий:

Действительно прост в использовании - простой (но мощный) графический интерфейс
Эффективная производительность - возможность профилировать приложения, которые находятся в чрезвычайно интенсивном использовании.
поддержка X64 и X32.
Понимает SQL, способен давать мне трассировки стека и продолжительность для всех моих вызовов SQL в сочетании с SQL.
Легко профилировать, не нужно проходить сложный процесс, перекомпилировать процесс приложения.
Простые профильные сервисы, веб-сайты и процессы, которые запускаются как побочные эффекты.
"Режим производства", который позволяет вам собирать ключевые данные из производственной системы.
- "Автоматический поиск узких мест": выполнить против производственного приложения и использовать эвристику, чтобы определить, какие методы медленны.
Анализ потоков, скажите, какие потоки выполняют всю работу и где.
Профиль в разных деталях позволяет выполнять "дешевый" профиль, который только собирает ключевую информацию и выкапывается с гранулированным профилированием.
Отслеживание исключений, позвольте мне отследить все исключения, которые выбрасываются в моем приложении (ключевая статистика и подробная информация).
Профилирование потоков - позволяет мне профилировать один поток в приложении

Ответ 3

Существует EQATEC Profiler, который является бесплатным профилировщиком .Net, который я хотел использовать.

Одна вещь, которую я хотел бы увидеть, это совместимость с Mono. Я начал заниматься в Mono, и было бы здорово иметь профилировщик .Net и Mono!

Ответ 4

Загрузите версию Visual Studio 2010 Beta 1 для Team Suite (бесплатно на 6 месяцев или около того?) И профилируйте приложение С#.

Доверьтесь мне. :)

Изменение: построчный режим помог мне изолировать оператора, который вызывал проблемы с производительностью. Я мог бы найти его без подсвечивания в каждой строке, но когда вы можете прокручивать и видеть горячие линии, используя его, вы можете легко исправить это.

Да, и если вам нужна обратная связь/помощь, свяжитесь со мной отдельно.

Сводный вид: выберите любой раздел диаграммы ЦП для фильтрации.

_{(источник: 280z28.org)}

Я люблю построчно на полях:

_{(источник: 280z28.org)}

Ответ 5

Если бы он сделал то же самое, что JetBrains dotTrace, я был бы очень счастлив.

Ответ 6

Я добавлю еще один пример, который будет действительно сладким. Сделайте простую сборку, имеющую функцию Mark(string), где, если приложение вызвало этот метод, то в результатах вы можете выбрать, чтобы увидеть результаты оттуда до (конец | какой-либо другой указанной метки). Другая возможность - BeginSequence и EndSequence или что-то еще. Двойной плюс, если вы можете указать, применяется ли метка только к текущему потоку или ко всем потокам.

Ответ 7

Что мне хотелось бы на профилировщике:

Должно работать на 32 и 64 бита
Должны иметь компоненты для всех уровней (клиент, сервер приложений, база данных) и некоторый способ их корреляции. Например, было бы неплохо увидеть, как изменения, внесенные в любой из уровней, влияют на другие уровни. Это может помочь решить, на каком уровне реализовать конкретные функции.
Интерфейс командной строки для использования с автоматическими сценариями (сервер сборки, стресс-тестирование и т.д.)
Должен иметь легкий режим выборки и более точный инструментальный режим. Второй должен повлиять на измерения выполнения как можно меньше.
GUI для удобства использования и должен генерировать необходимые файлы конфигурации для использования режима em comand line
Создание результатов в формате starndard (если такая вещь существует), поэтому я могу использовать результаты с другими инструментами
Следует также генерировать или экспортировать результаты в формат Visual Studio (*.vsp)
Сравните между двумя или более файлами результатов, чтобы увидеть эволюцию или регрессию базы кода.
Соберите и сопоставьте данные целевого приложения с данными PerfMon других процессов, запущенных на каждом целевом компьютере, для идентификации одновременного использования ресурсов (память, процессор, диск и сетевой ввод-вывод)
Определите пороговые значения, для которых должен быть вызван некоторый механизм предупреждения. Примером такого может быть электронная почта, если конкретный сценарий занимает больше времени, чем указано.
Hability для прикрепления и отсоединения от выполняемого процесса для сбора данных выборки без вмешательства в целевое приложение. Должно быть для использования на производственных площадках.

Ответ 8

Phsr уже упоминает EQATEC Profiler.

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

Ответ 9

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

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

Общие взгляды на настройку производительности, которые преподаются в школе (профессорами с небольшим воздействием на реальное программное обеспечение) и продолжаются через 50 000-программистов, не могут быть неправильным явлением, я предлагаю поставить под сомнение и надел более прочную основу. Я далек от одиночества, чувствуя это так, как вы можете собраться из круиза вокруг SO.

Я думаю, что технология профилировщика постепенно развивается (к лучшему, на мой взгляд) к выборке стека и способам исследования результатов. Вот о чем я могу зависеть (что может показаться немного затруднительным):

Раскрытие проблем с производительностью, чтобы их можно было фиксировать и измерить производительность, - это две совершенно разные задачи. Это средства и цели, и их не следует путать.
Чтобы выявить проблемы с производительностью, необходимо выяснить, какие виды деятельности учитывают большие количества времени настенных часов и их можно заменить чем-то быстрее.
Приятная вещь в таких действиях заключается в том, что сам факт, что они требуют времени, подвергает их случайным выборкам состояния программы.
Не требуется много образцов, если они берутся в течение интересующего вас интервала. То есть нет смысла брать образцы во время ожидания ввода пользователя. С этой целью, в моем профилировщике, я позволяю пользователю запускать сэмплы с ключами.
По этой причине вам не нужно много образцов. Любая заданная проблема производительности требует некоторую долю X времени настенных часов в интересующем интервале. Случайная выборка в этом интервале имеет вероятность X "поймать ее в действии", поэтому, если взяты N выборок, ожидаемое количество выборок, захватывающих ее в действии, равно NX. Стандартное отклонение этого числа образцов - sqrt (NX (1-X)). Например, если N = 20 и X = 20%, вы можете ожидать от 2 до 6 образцов, чтобы показать проблему. Это дает вам неточную меру проблемы, но это говорит о том, что ее стоит исправлять, и она дает вам очень точное местоположение без дальнейшей детективной работы.
Проблемы обычно проявляются как больше вызовов функций, процедур или методов, чем необходимо, особенно по мере того, как программное обеспечение становится большим, с большим количеством слоев абстракции и, следовательно, с большим количеством уровней стека. Первое, что я ищу, это сайты вызовов (а не функции, а вызывные инструкции или инструкции), которые появляются в нескольких образцах стека. Чем больше образцов стека они появляются, тем больше они стоят. Вторая вещь, которую я ищу, - "их можно заменить?" Если они абсолютно не могут быть заменены чем-то быстрее, то они просто необходимы, и мне нужно искать в другом месте. Но часто их можно заменить, и я получаю приятное ускорение. Поэтому я внимательно смотрю на конкретные образцы стека, а не на их объединение в измерения.
Рекурсия не является проблемой, потому что принцип, согласно которому стоимость инструкции представляет собой процент времени, установленного в стеке, одинаков, даже если он вызывает себя.
Это не то, что я делаю один раз, а последовательные проходы. Каждая проблема, которую я исправляю, заставляет программу занимать меньше времени. Это означает, что другие проблемы становятся большими долями времени, что облегчает их поиск. Этот эффект объединяет, так что часто возможны резкие кумулятивные улучшения производительности.

Я мог бы продолжить, но я желаю вам удачи, потому что я думаю, что есть необходимость в улучшенных инструментах профилирования, и у вас есть хорошие шансы.

Ответ 10

Было бы неплохо, если бы связанные с .NET профилирования из Perfmon были интегрированы, так что вы избегаете "двойного" мониторинга с помощью perfmon и вашего приложения. Это полезно для всех элементов, связанных с памятью.

Ответ 11

Мой предпочтительный профилировщик был "DevPartner Performance Analysis Community Edition" (http://researchlibrary.theserverside.net/detail/RES/1165507815_474.html?psrc=MPR), к сожалению, он больше не доступен.

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

Второе требование было бы "простота использования", то есть он должен работать со всеми соответствующими типами приложений, windows exe, веб-приложением, службой Windows, службой WCF (Silverlight?),.... И не только с маленькими примерными приложениями, но и с нестандартными приложениями с размерами предприятия.

Ответ 12

Я бы хотел по крайней мере некоторую совместимость с ASP.NET, хотя я понимаю, что на самом деле довольно сложно заставить это работать.

Линия за строкой настолько хороша в Shark, что я также хотел бы иметь ее в .NET.

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

Ответ 13

Несколько вещей, которые мне очень хотелось бы увидеть:

Сбор данных:

Возможность разрешить отслеживание контекста через новый поток. То есть, когда происходит вызов любого нового Thread() или ThreadPool.Queue...(), подсчитайте работу, выполняемую другим потоком, как если бы это произошло внутри вызывающей функции, даже если они встречаются в разных потоках, и вызывающий метод на самом деле не блокирует. Это в конечном итоге позволит идентифицировать код, который дает много работы в общем методе, который реализует шаблон асинхронизации. Это действительно может быть здорово!
Отслеживание распределения внутри методов. Есть шанс, что профилировщик .Net памяти уже делает это, но определение того, какие методы выполняют многие распределения, может быть неоценимым. Даже если другие инструменты могут это сделать, все в одном инструменте всегда велико.
Агрегация, способная обнаруживать "всплески" при использовании и анализе только их. Это может быть удобно при анализе фонового процесса, который неправильно работает и нечасто.

конец пользовательского интерфейса:

Возможность сравнить два прогона и выделить основные различия между ними.
Вызов дерева вызовов и расширение горячего пути (VS-стиль) тоже будут отличными.

Ответ 14

Одна из вещей, которые я делаю практически во всех профилях, - это управляемый API для выполнения автоматизированных профилирования и автоматических тестов.

Я могу представить, что вы думаете, WTF... почему бы вам хотелось автоматизировать профилирование?

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