我知道我可以在Linux上使用gprof和kprof来分析我的代码。 Windows上是否有与这些应用程序类似的替代方案？
答案 0 :(得分：3)
gprof的MinGW端口与Linux变体的工作方式大致相同。你可以获得一个完整的MinGW installation（我认为包含gprof但不确定）或从MinGW binutils package获得gprof。
对于Eclipse，有TPTP但据我所知它不支持分析C / C ++。
答案 1 :(得分：3)
商业软件：
免费软件：
这些商业替代方案通过“检测”（添加指令）来更改已编译的代码，并使用添加的指令执行计时。这意味着它们会严重降低您的应用程序速度。
这些免费替代品使用抽样，这意味着它们不那么详细，但速度非常快。在实践中，我发现特别是Very Sleepy非常适合快速查看应用程序中的性能问题。
答案 2 :(得分：0)
是的，您可以对代码with Visual Studio
进行分析答案 3 :(得分：0)
分析的原因是什么？您想a）测量时间并获得调用图，或者b）找到要更改的内容以使代码更快？ （这些不一样。）
如果（b）你可以使用this trick，使用Eclipse中的Pause按钮。
补充：也许它可以帮助传达一些关于性能问题实际上是什么样的经验，以及你可以在哪里找到它们。以下是一些简单的例子：
插入排序（顺序n ^ 2），其中要排序的项目是字符串，并通过字符串比较函数进行比较。热点在哪里？在字符串比较中。问题出在哪儿？在调用string-compare的sort中。如果n = 10则不是问题，但如果n = 1000，则突然需要很长时间。调用string-compare的点是“冷”，但这就是问题所在。调用堆栈的少量样本可以确定地确定它。
加载插件的应用程序需要很长时间才能启动。一个分析器说基本上所有东西都是“冷”。测量I / O时间的东西说它几乎都是I / O时间，这看起来像你可能期望的那样，所以看起来似乎没有希望。但是，堆栈示例显示，在读取插件dll的资源部分以将字符串常量转换为本地语言的过程中，堆栈大约花费20层深度花费了大量时间。进一步调查，您发现翻译的大多数字符串不是实际需要翻译的字符串。他们只是放在“万一”他们可能需要翻译，并且从未被认为是可能导致性能问题的东西。解决这个问题可以节省大量时间。
因此，通常会考虑“热点”和“瓶颈”，但大多数程序，特别是较大的程序，往往会以函数调用的形式出现性能问题，请求工作并不需要完成。幸运的是，在他们花费的时间里，他们会在调用堆栈中显示自己。