VS2010分析器：是否可以分析一种特定方法？
可能有一些方法可以打开和关闭代码分析？
或者您可以选择要分析的特定函数吗？
Possibly some methods to turn on and turn off profiling from code?
Or can you select a specific function to profile ?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
您还可以使用分析器的数据收集 API 来启动和停止围绕您感兴趣的方法进行分析。请参阅 这篇 MSDN 文章 提供了演练。
在这种情况下，使用 API 的最佳方法是在方法执行之前调用
StartProfile，然后在执行之后调用StopProfile。您应该通过“开始时暂停分析”选项开始分析，这样在第一次调用StartProfile之前您不会开始分析。使用数据收集 API 将与采样或仪器配合使用。
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
StartProfilejust before your methods execute and then callStopProfilejust after. You should start profiling via the "Start With Profiling Paused" option so you don't start profiling until you hit the first call toStartProfile.Using the data collection API will work with sampling or instrumentation.
是的，如果您进行仪器分析（而不是采样），您可以通过一点努力来做到这一点：
/include:ConsoleApp.Program::Main,MyNamespace.MyClass::MyFunc）/include语法有点奇怪，但是如果您启动 VS 命令提示符并转到二进制文件的目录，则可以运行vsinstr.exe /dumpfuncs foo.exe 查看可以显式包含的方法列表。有关详细信息，请参阅vsinstr.exe 命令行语法。
Yes, with a little effort, you can do this if you do instrumentation profiling (not sampling):
/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 runvsinstr.exe /dumpfuncs foo.exeto see the list of methods you can explicitly include.See the vsinstr.exe command-line syntax for more info.
不。
您正在寻找“瓶颈”，对吗？
它可能不在您认为的功能中。
这是我的方法依赖于任何语言或操作系统。
如果问题出在该函数中，它会告诉您。如果它在其他地方，它会告诉你。
@downvoter：有什么问题吗？如果您关心应用程序启动速度，请在应用程序启动过程中手动采样。
探查器中的替代方法是全程运行它，然后尝试找出时间线的哪一部分是启动的。由于大部分时间都花在用户等待上，当您不需要样本时，您可以将其置于 CPU 采样模式。这样做的问题是，您看不到诸如加载 dll、查询 DNS 等所花费的 I/O 时间之类的事情，这些事情在启动期间可能占主导地位。
然后就是像“热路径”这样的愚蠢的演示问题，真正的时间掌握者可以轻松隐藏 。
如果您问“我如何检查数千个堆栈样本？”答案是你不需要。如果初创公司的速度明显缓慢，那是因为它花费了很大一部分时间做一些不需要做的事情——保守地说，大约有 30% 的时间。
这意味着平均每 3.33 个样本您就会看到一次。
由于您需要查看两次或多次才能知道这是一个问题，因此平均需要 6.67 个样本。
问题越大，需要的样本就越少。
（如果是 90%，则只需要 2/0.9 = 2.2 个样本。）
如果你检查 20 个样本，你会发现任何问题的成本都超过 10%，如果你解决了它，任何较小的问题都会占据更大的百分比 - 它们会被加速比放大，因此下次更容易找到它们-大约。
这是数学计算。
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.