VS2010 profiler : is it possible to profile one specific method?

Possibly some methods to turn on and turn off profiling from code?

Or can you select a s开发者_如何学编程pecific function to profile ?

---

You can also use the profiler's data collection API to start and stop profiling around the methods you're interested in. See this MSDN article for a walkthrough.

The best way to use the API in this case would be to call StartProfile just before your methods execute and then call StopProfile just after. You should start profiling via the "Start With Profiling Paused" option so you don't start profiling until you hit the first call to StartProfile.

Using the data collection API will work with sampling or instrumentation.

---

Yes, with a little effort, you can do this if you do instrumentation profiling (not sampling):

1. Add your binary/project as a Target in Performance Explorer
2. Right-click on the target, click Properties
3. Go to the Instrumentation section, uncheck "Exclude small functions..."
4. Go to the Advanced section, under "Additional instrumentation options", specify the methods you specifically want to profile (e.g. /include:ConsoleApp.Program::Main,MyNamespace.MyClass::MyFunc)

The /include syntax is a little weird, but if you launch a VS command prompt and go to your binary's directory, you can run vsinstr.exe /dumpfuncs foo.exe to see the list of methods you can explicitly include.

See the vsinstr.exe command-line syntax for more info.

---

Don't.

You are looking for "the bottleneck", right?

It's probably not in the function where you think it is.

This is the method I rely on, for any language or OS.

If the problem is in that function, it will tell you. If it is somewhere else, it will tell you.

---

@downvoter: What's the problem? If you are concerned about speed of application startup, manually take samples during application startup.

The alternative in a profiler is to run it over the whole time and then try to figure out which part of the timeline was the startup. And since much of the time is spent in user-wait, when you don't want samples, you put it in CPU-sampling mode. The trouble with that is, you don't see things like I/O time spent loading dlls, querying DNS, etc., which can be dominant during startup.

Then there's the whole issue of presentation silliness like "hot path", where the true time-taker can easily hide.

In case you're asking "How can I examine thousands of stack samples?" the answer is you don't need to. If the startup is noticeably slow, it is because it is spending some large fraction of its time doing something it doesn't need to do - some fraction like, say, 30%, to be conservative. That means you will see it, on average, once every 3.33 samples. Since you need to see it two or more times to know it is a problem, on average you need 6.67 samples. The bigger the problem is, the fewer samples you need. (If it's 90%, you only need 2/0.9 = 2.2 samples.) If you examine 20 samples, you will see any problem costing more than about 10%, and if you fix it, any smaller problems take a larger percent - they are amplified by the speedup ratio, so they are easier to find on the next go-around. Here's the math.