Это на самом деле плохой пример - обычно вы бы не описали что-то тривиальное.
В конечном счете, это то, что вы хотите профилировать. Есть ловушка для таких вещей, как ADO.NET, но если вы хотите, чтобы она профилировала вещи вне этого, да: вам нужно помочь.
Re "замусорил", ну, это субъективно. И лучший подход, как правило, состоит в том, чтобы ограничить инструментарий операциями очень высокого уровня , а затем увеличивать масштаб только с более детальными операциями, как вам нужно (из-за выявленного проблемного места); например, вы можете иметь:
...
using(profiler.Step("Refresh customer"))
{
// ...
}
...
и только тогда, когда вы обнаружите, что увеличение на 1800 мс:
...
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(...) для отдельных команд.
Независимо от того, считаете ли вы это "мусором":
- подчеркивает производительность - это функция (и действительно, часто это требование) - нормально иметь код для поддержки ваших функций! Действительно, это форма свидетельства того, что вы рассматривали (и измеряли) производительность нового / измененного фрагмента кода
- все зависит от контекста, насколько гранулярно вы это делаете
- поэтому он обеспечивает значимый уровень детализации для пользователя - без безумных мелочей в журнале и без влияния на производительность большинства журналов