有这么多可用的系统资源,你有多确定你的代码已经过调优?

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

如果你在设计问题的解决方案时始终牢记优化,那么你应该能够编写可读的代码,其他开发人员会对此表示赞同。此外,如果你正在用一种更高级的语言进行编程,在运行之前会进行编译,请记住,编译器现在会进行一些你或我可能没有想到的很棒的优化,而且(更重要的是)也不必担心。

坚持使用一个好的、低的大O(),它应该被优化得很好。如果你在某种类型的数据集中处理数百万或更多的数据,那么寻找一个大的O(logn)算法。它们非常适合大型任务,并使您的代码保持优化。

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

有时确实需要逐行优化,如果你需要那么快的速度,也许你可以研究汇编,这样你就可以控制每一行。

“好”代码和“快”代码之间有很大的区别。它们也不是完全独立的,但“快速”代码并不意味着“好”。通常,“快速”实际上意味着糟糕的代码,因为必须牺牲可读性才能使其快速。

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

如果你的代码很慢,但你不知道为什么,我会使用一个分析器,比如 ANT ,或 dotTrace 如果你在。NET世界(我相信还有其他平台和语言)。它们非常有用,但我只遇到过一次需要分析器来识别问题的情况。现在我知道了这个问题,我不需要再使用分析器来告诉我这是一个问题,因为我永远不会忘记我花了多少时间试图优化它。

这绝对是一个合理的担忧,但对大多数开发人员来说并非如此。大多数开发人员关心的是获得一款适合雇主的产品。优化代码很少是必需的。

确保代码快速的最佳方法是对其进行基准测试或分析。许多编译器优化会在程序员代码的性能中产生非直观的异常,因此最终测量变得至关重要。

根据我的经验, Rational Quantify 在代码调优方面给了我最好的结果。它不是免费的,但功能非常齐全,似乎给了我最有用的结果。

关于免费工具,请查看 gprof 或 oprofile ,如果你在Unix环境中。它们不如一些商业工具好,但通常可以为你指明正确的方向。

顺便说一句,我几乎总是对我第一次使用分析器时出现的结果感到惊讶。你可以凭直觉判断代码的瓶颈在哪里,而且往往是完全错误的。

我写的几乎所有代码都足够快。在极少数情况下,如果不是这样,对于C、C++和Objective-Caml,我会使用古老的 gprof 和优秀的 valgrind 凭借其卓越的可视化工具 kcachegrind (KDE SDK的一部分;不要被sourceforge上过时的代码所愚弄)。

这个 MLton 标准ML编译器和 Glasgow Haskell Compiler 两者都配有出色的轮廓仪。

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

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