С мини-профайлер
при использовании мини-профилировщика это означает, что производственный код будет "замусорен" с использованием блоков?
using (profiler.Step("Set page title"))
{
ViewBag.Title = "Home Page";
}
Я думаю, если это 1-off тестирование, я мог бы удалить его, но обычно вы хотите сохранить их в кодовой базе для постоянного профилирования.
1 ответов
это на самом деле плохой пример - обычно вы не профилируете что-то тривиальное.
В конечном счете, это выборный, что вы хотите профиль. Есть крючок для таких вещей, как ADO.NET, но если вы хотите, чтобы он профилировал вещи за пределами этого, да: вы должны дать ему руку.
Re "замусорено", ну, это субъективно. И лучший подход, как правило, ограничить инструментарий до очень высокий уровень операции, а затем только увеличивать с более детализированными операциями, как вы обнаружите, вам нужно (из-за выявленного проблемного места); например, у вас может быть:
...
using(profiler.Step("Refresh customer"))
{
// ...
}
...
и только тогда, когда вы обнаружите, что принимая 1800ms зум:
...
using(profiler.Step("Refresh customer"))
{
using(profiler.Step("Query LDAP"))
{ ... }
using(profiler.Step("Query primary customer DB"))
{ ... }
using(profiler.Step("Query aux db"))
{ ... }
using(profiler.Step("Print, scan, and OCR"))
{ ... }
}
...
есть .Inline(...)
метод для отдельных команд.
считаете ли вы, что это "мусор":
- акцент производительность (и действительно, часто требование) - нормально иметь код для поддержка Ваших возможностей! В самом деле, это форма доказательства того, что у вас есть считается (и измеряется) производительность нового / измененного фрагмента кода
- это полностью контекстуальный, как гранулированный вы делаете это
- поэтому он предоставляет пользователю значимый уровень детализации-без безумного количества пустяков в журнале и без инвазивного характера большинства журналов