visual-studio VS2010 分析器：是否可以分析一种特定方法？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/2759440/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
VS2010 profiler : is it possible to profile one specific method?
提问by rekna
Possibly some methods to turn on and turn off profiling from code?
可能有一些方法可以从代码中打开和关闭分析？
Or can you select a specific function to profile ?
或者你可以选择一个特定的功能来分析？
回答by Chris Schmich
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 articlefor a walkthrough.
您还可以使用探查器的数据收集 API 来启动和停止围绕您感兴趣的方法进行探查。有关演练，请参阅此 MSDN 文章。
The best way to use the API in this case would be to call StartProfilejust before your methods execute and then call StopProfilejust 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.
在这种情况下使用 API 的最佳方法StartProfile是在方法执行之前调用，然后在执行之后调用StopProfile。您应该通过“Start With Profiling Paused”选项开始分析，这样在您第一次调用StartProfile.
Using the data collection API will work with sampling or instrumentation.
使用数据收集 API 将适用于采样或检测。
回答by Chris Schmich
Yes, with a little effort, you can do this if you do instrumentation profiling (not sampling):
是的，稍加努力，如果您进行仪器分析（不是采样），您就可以做到这一点：
- Add your binary/project as a Target in Performance Explorer
- Right-click on the target, click Properties
- Go to the Instrumentation section, uncheck "Exclude small functions..."
- 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)
- 在性能资源管理器中将您的二进制文件/项目添加为目标
- 右键单击目标，单击属性
- 转到 Instrumentation 部分，取消选中“Exclude small functions...”
- 转到高级部分，在“其他检测选项”下，指定您特别想要分析的方法（例如
/include:ConsoleApp.Program::Main,MyNamespace.MyClass::MyFunc）
The /includesyntax 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.exeto see the list of methods you can explicitly include.
该/include语法是有点怪异，但如果你推出一个VS命令提示符，然后转到您的二进制文件的目录，你可以运行vsinstr.exe /dumpfuncs foo.exe，看的方法列表，你可以明确地包括。
See the vsinstr.exe command-line syntaxfor more info.
有关详细信息，请参阅vsinstr.exe 命令行语法。
回答by Mike Dunlavey
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.
@downvoter：有什么问题？如果您担心应用程序启动的速度，请在应用程序启动期间手动取样。
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.
分析器中的替代方法是在整个时间内运行它，然后尝试找出时间线的哪一部分是启动。而且由于大部分时间都花在用户等待上，当您不想要样本时，您可以将其置于 CPU 采样模式。这样做的问题是，您看不到加载 dll、查询 DNS 等所花费的 I/O 时间，这些在启动期间可能占主导地位。
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.
如果您问“我如何检查数千个堆栈样本？” 答案是你不需要。如果启动速度明显缓慢，那是因为它花费了很大一部分时间做一些它不需要做的事情——保守地说，有一部分时间，比如 30%。这意味着您平均每 3.33 个样本就会看到一次。由于您需要查看两次或更多次才能知道这是一个问题，因此平均需要 6.67 个样本。问题越大，您需要的样本就越少。（如果是 90%，你只需要 2/0.9 = 2.2 个样本。）如果你检查 20 个样本，你会发现任何问题的成本超过 10%，如果你修复它，任何较小的问题都会占据更大的百分比 - 他们被加速比放大，因此在下一次复飞时更容易找到它们。 这是数学。
