随着CPU越来越快，硬盘旋转，数据飞得如此之快，网络速度也越来越快，从过去的良好代码中判断坏代码并不是那么简单。
我记得有一段时间你可以优化一段代码，并且无可否认地看到了性能的提升。那些日子快结束了。相反，我想我们现在有一套规则，我们遵循“不要在循环中声明变量”等。坚持这些是很好的，这样你就可以默认编写好的代码了。但是，如果没有一些工具，你怎么知道它无法进一步改进？
有些人可能会争辩说，如今几纳秒不会真正发挥重要作用。事实是，我们坚持这么多层，你会得到惊人的效果。
我并不是说我们应该从代码中优化每一毫秒，因为这将是昂贵且不可行的。我认为，考虑到我们的时间限制，我们必须尽力编写有效的代码。
我只是想知道您使用什么工具来分析和衡量代码的效果（如果有的话）。
答案 0 :(得分：4)
我认为优化应该被认为不是看每行代码，而是渐进复杂度是你的算法。例如，使用冒泡排序可能是您在优化方面可以使用的最差排序算法之一。这花费的时间最长。 Quicksort和mergesort在排序方面更快，应该在冒泡排序之前使用。
如果在设计问题解决方案时始终牢记优化，那么您应该能够编写可读代码，其他开发人员会批准这些代码。此外，如果您使用将在运行之前编译的更高级语言进行编程，请记住编译器现在进行一些非常棒的优化，您或我可能没有想到，并且（更重要的是）不必担心。
坚持使用优秀的低O（），它应该优化得非常好。如果您在某种类型的数据集中使用数百万或更多，那么请寻找一个大的O（logn）算法。它们适用于大型任务，并保持代码优化。
让编译器逐行优化，以便您可以专注于解决方案。
有时候需要逐行优化，如果你需要那么快的话，也许你可能想要查看汇编，这样你就可以控制所写的每一行。
答案 1 :(得分：3)
“好”代码和“快速”代码之间存在很大差异。它们也不完全相互独立，但“快速”代码并不意味着“好”。通常，“快速”实际上意味着代码不好，因为必须做出可读性妥协才能使其快速。
我看待它的方式，hardware is cheap, programmers are expensive。除非某些代码存在严重的性能问题，否则您永远不必担心速度问题。如果存在性能问题，您会注意到它们。只有当您注意到良好硬件上的性能问题时，您才需要担心优化（在我看来）
如果你的代码很慢，但你无法找出原因，我会使用ANT或dotTrace等分析器，如果你在.NET中世界（我确信还有其他平台和语言）。它们非常有用，但我只有一种情况需要一个分析器来识别问题。现在我知道这个问题，我不再需要一个分析器来告诉我这是一个问题，因为我永远不会忘记我花在试图优化它上面的时间。
答案 2 :(得分：0)
这绝对是一个有效的问题，但对大多数开发人员来说并非如此。大多数开发人员都关心如何获得适合其雇主的产品。优化的代码很少是必需的。
确保代码快速的最佳方法是对其进行基准测试或分析。许多编译器优化会在程序员代码的性能中产生非直观的奇怪现象，因此最终测量变得至关重要。
答案 3 :(得分：0)
根据我的经验，Rational Quantify在代码调优方面给了我最好的结果。它不是免费的，但功能非常全面，似乎给了我最有用的结果。
就免费工具而言，如果您使用的是Unix环境，请查看gprof或oprofile。它们不如某些商业工具那么好，但通常可以指向正确的方向。
另一方面，我几乎总是惊讶于我第一次使用它们时会发现个人资料。您可以直观地了解代码可能存在瓶颈的地方，而且通常可能完全错误。
答案 4 :(得分：0)
我写的几乎所有代码都足够快。在极少数情况下，对于C，C ++和Objective Caml，我使用古老的gprof和优秀的valgrind及其精湛的可视化器kcachegrind（KDE SDK的一部分） ;不要被sourceforge上的过时代码所迷惑。）
MLton标准ML编译器和Glasgow Haskell Compiler都附带优秀的分析器。
我希望Lua有更好的分析器。
答案 5 :(得分：-1)