С мини-профайлер

при использовании мини-профилировщика это означает, что производственный код будет "замусорен" с использованием блоков?

using (profiler.Step("Set page title"))
{
    ViewBag.Title = "Home Page";
}

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

6

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(...) метод для отдельных команд.

считаете ли вы, что это "мусор":

  • акцент производительность (и действительно, часто требование) - нормально иметь код для поддержка Ваших возможностей! В самом деле, это форма доказательства того, что у вас есть считается (и измеряется) производительность нового / измененного фрагмента кода
  • это полностью контекстуальный, как гранулированный вы делаете это
  • поэтому он предоставляет пользователю значимый уровень детализации-без безумного количества пустяков в журнале и без инвазивного характера большинства журналов
9