With the mini-profiler

When using the mini profiler, does this mean production code will be 'littered' with using blocks?

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

I gues开发者_C百科s if it is 1-off testing I could remove it, but usually you want to keep these in the codebase for constant profiling.

That is actually a bad example - you wouldn't normally profile something trivial.

Ultimately, it is elective what you want to profile. There's a hook for things like ADO.NET, but if you want it to profile things outside of this, yes: you need to give it a hand.

Re "littered", well, that is subjective. And the best approach is usually to limit the instrumentation to very high level operations, and then only zoom in with more granular operations as you find you need to (due to an identified problem spot); for example, you might have:

...
using(profiler.Step("Refresh customer"))
{
    // ...
}
...

and then only when you find that taking 1800ms zoom in:

...
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"))
    { ... }
}
...

There is also an .Inline(...) method for individual commands.

Whether or not you think this is "littering":

• it emphasises performance is a feature (and indeed, often a requirement) - it is OK to have code to support your features! Indeed, it is a form of evidence that you have considered (and measured) performance of a new / altered piece of code
• it is entirely contextual how granular you make it
• it therefore provides a meaningful level of detail to the user - without insane amounts of trivia in the log, and without the performance-invasive nature of most logging