如果通过“重构”你的意思只是重命名事物，从一个函数中分解代码并将其放入另一个函数中，等等，那么答案是结果可能是噪音。当然会有差异，因为编译器编译不同的代码，但不会很多。

通过更改您所做工作背后的算法，您可以显着提高速度。但这通常不称为“重构”。

换句话说，这完全取决于您使用“重构”一词时的确切含义。

通常，人们将糟糕的代码、代码异味或任何你喜欢的名称称为程序员生产力低下的代码。我认为我们可以同意糟糕的代码是复杂且难以维护的。重构只是从人类角度提高代码质量的指导方针。

计算机性能是一个不同的问题，简而言之，就是计算机相对于其最大容量执行了多少有用的工作。因此，性能并不关心一个人是否可以轻松阅读代码，维护或扩展代码的难易程度。

那么，当两个代码实现相同的功能甚至相同的算法时，杂乱的代码是否能比可读、可维护和不太复杂的代码实现更高的性能呢？答案取决于这些代码映射到底层架构的程度，以便生成的程序能够有效且高效地使用硬件。

例如，考虑到手动调优的高性能代码（紧密映射到底层硬件）通常不容易阅读、维护或扩展......根本不方便！如果您对此感到好奇，您可以查看高性能（直到最近）GotoBLAS 库的源代码，看看它有什么味道。手动调整的高性能代码的缺点是不易阅读或维护。

正如 Mike Dunlavey 在评论中提到的，对于大多数软件来说，好的代码和生产力不一定是相反的目标，代码可以同时在两个方向上得到改进。但是，您越接近硬件的最大性能（大多数软件并非如此，因此对高性能 GotoBLAS 的引用）更重要的是从代码中的表达式到在硬件上有效运行的指令的映射。在这一点上，您可能会担心难以维护和调整的硬件特定功能，例如缓存大小、线程亲和性、向量指令、页面错误等。我应该补充一点，良好的代码实践使开发高性能应用程序变得非常重要更容易的工作，因为您很可能需要维护和扩展此类代码。

程序员生产力和计算机性能之间的平衡是高性能科学计算的主要挑战之一。有很多尝试解决这个问题的举措：高级编译器、自动调整代码、新的编程语言、特定领域的语言、编程模式和指南等。

您所做的任何重构都可能会影响方法的速度，使方法变慢或变快。很多时候，重构是通过改变方法内部使用的实际算法来完成的。以在基本 CS 课程中学到的东西为例：排序。

假设您有一个方法sort，它接收一个事物列表并输出相同的列表，但已排序。您最初使用冒泡排序，但后来重构该方法以使用快速排序。您的方法现在通常更快。

如果您对软件的速度有任何疑虑，那么我建议您首先集中精力，就像在这篇文章中一样。

您为提高速度所做的任何事情都会更改代码，因此看起来像是重构。

您为清理代码所做的任何更改都可能使其速度更快，也可能使其速度变慢。

所以无论如何都要清理它，但如果性能是一个问题（也许不是），那就把它作为你的主要关注点。