This is actually a bad example - you usually don't profile something trivial.
Ultimately, it is the choice that you want to profile. There is a hook for things like ADO.NET, but if you want him to have a profile beyond that, yes: you need to give him a hand.
Re "littered", well, it's subjective. And the best approach, as a rule, is to limit the tools to a very high level , and then only increase the scale with the more detailed operations that you need (due to the identified problem location); for example, you might have:
... using(profiler.Step("Refresh customer")) {
and only when you find that with an increase of 1800 ms:
... 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 a .Inline(...) method for individual commands.
Do you think this is "trash":
- he emphasizes performance - this is a function (and indeed, often a requirement) - it is normal to have code to support your functions! Indeed, this is one form of proof that you have reviewed (and measured) the performance of the new / changed part of the code.
- it is completely contextual as far as you are granular.
- therefore, it provides a significant level of detail for the user - without the crazy amount of detail in the magazine and without the aggressive nature of most magazines