25

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

Or can you select a specific function to profile ?

John Saunders
  • 160,644
  • 26
  • 247
  • 397
rekna
  • 5,313
  • 7
  • 45
  • 54

3 Answers3

31

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.

Chris Schmich
  • 29,128
  • 5
  • 77
  • 94
  • This DLL no longer exists after Visual Studio 2017. If anyone knows how to do this with VS2022 please update this answer. – Moby Disk Apr 14 '23 at 20:28
17

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.

Chris Schmich
  • 29,128
  • 5
  • 77
  • 94
-1

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.

Community
  • 1
  • 1
Mike Dunlavey
  • 40,059
  • 14
  • 91
  • 135
  • sometimes you just want to limit the scope to one specific part of the application... eg. a web application takes a long time to start (just because it has a lot to do), but I want to check how one specific part in the startup process behaves, the ones that I wrote, not the code that the infrastructure of an asp.net application executes. – rekna May 03 '10 at 19:11
  • @rekna: OK, then if you can run it under a debugger, take stack samples. If your routine is on the stack less than 10% of the time, then chances are it's not worth speeding up - that's your call. If it is on the stack more often than that, then the samples will tell you exactly how it spends its time (i.e. where is it calling what, and what is *that* calling, etc) on a percentage basis. That's what will lead you directly to code you can speed up, assuming there is some. (Usually there is.) – Mike Dunlavey May 03 '10 at 19:22
  • @rekna: .net applications tend to do a whole lot of hoo-ha during startup - things you would never guess, and they might be under your code and might not. Loading plugins, loading resources, initializing data structures, loading UI controls, initializing grids, all these things are notorious for wandering off on wild goose chases of code. – Mike Dunlavey May 03 '10 at 19:30
  • 4
    I don't agree with this advice. There are times when you know that a particular part of your application is slow and that's what you want to profile. There's nothing wrong with telling the system to not profile sections of code you're not interested in optimize, especially since profiling can significantly reduce the speed of the program execution. – zumalifeguard Sep 10 '14 at 20:04
  • @zuma: People are not good at guessing what the problem is. But it doesn't matter. Even if they have a guess where it is, if they are right, the samples will confirm it. If they are wrong, the samples will tell them what the problem really is. The problem with restricting the profiler's attention is - if they are wrong, they cannot find out. – Mike Dunlavey Sep 10 '14 at 21:30