有这么多可用的系统资源,您有多确定您的代码是否经过了调优?

我认为优化不应该被认为是在看每一行代码,而是你的算法的渐进复杂性。例如,在优化方面,使用冒泡排序可能是最糟糕的排序算法之一。时间最长。快速排序和合并排序在排序方面更快,并且应始终在冒泡排序之前使用。

坚持使用一个好的和低的大O(),它应该得到很好的优化。如果您在某种类型的数据集中处理数百万或更多数据,那么请寻找大O(logn)算法。它们对于大型任务非常有效,并使您的代码保持最佳状态。

让编译器进行逐行代码优化,这样您就可以专注于解决方案。

有时确实需要逐行优化,如果您需要这么快的速度,那么您可能希望查看汇编以便可以控制编写的每一行。

在我看来, hardware is cheap, programmers are expensive . 除非某段代码存在严重的性能问题,否则永远不必担心速度。如果存在性能问题,您会注意到它们。只有当你注意到好硬件的性能问题时,你才应该担心优化(在我看来)

如果您的代码速度很慢,但您无法找出原因,我会使用类似的分析器 ANT 或 dotTrace 如果你身处.NET世界(我相信还有其他平台和语言)。它们非常有用,但我只遇到过一种情况,需要一个分析器来识别问题。现在我知道了这个问题,我不再需要剖析器来告诉我这是个问题,因为我永远不会忘记我花了多少时间来优化它。

这绝对是一个值得关注的问题,但对大多数开发人员来说并非如此。大多数开发人员关心的是得到一个对他们的雇主有用的产品。优化的代码很少是必需的。

根据我的经验, Rational Quantify

关于免费工具,请查看 gprof 或 oprofile

另一方面,我几乎总是对分析器在我第一次使用时出现的情况感到惊讶。您可以凭直觉判断代码在哪里可能会成为瓶颈,而且常常是完全错误的。

gprof 还有最棒的 valgrind 用它的超级可视化工具 kcachegrind

这个 MLton 标准ML编译器及其应用 Glasgow Haskell Compiler 两艘船都配备了优秀的剖面仪。

我希望有一个更好的分析器 Lua

嗯,也许是一个剖析器?几乎所有的平台和语言都有可用的。