6

当我使用具有很多（超过一百个）参数的拥有/使用方法时，它在计算性能方面是否效率低下？

我并不是说在可维护性方面高效，而只是在“原始”计算性能方面:)

4

6 回答 6

4

从理论上讲，也许，由于 Java 是按值传递的，这意味着当调用函数时，JVM 会复制每个参数值并将副本提供给函数，因此可能存在某个点参数的数量对执行时间有不可忽视的影响。但在实践中，只要有可能，这些副本都是“浅”副本，这意味着它们更像是参考，因此实际制作副本的时间很少。因此，您可能需要超过 100 个参数才能对性能时间产生任何明显影响。

无论如何，即使考虑到这样的性能时间，听起来也很像过早的优化。它几乎肯定不是您的程序的瓶颈，因此在您确定它实际上导致减速之前不值得花时间。如果您的程序速度慢得令人无法接受，请调查其他可能的减速源。

当然，正如您提到的，还有“可维护性”问题。为什么单个函数需要数百个参数？它们是复杂的参数，例如自定义对象的 ArrayLists，还是简单的内置数据类型？如果是后者，为什么不考虑将它们打包成数组、ArrayList 等呢？或者，为什么不将功能分解为多个功能呢？现代计算机足够快，以至于对于许多（可以说是大多数）目的来说，程序员的时间比处理器的时间更有价值，所以在编码时，你首先关心的通常应该是你所写的内容是否易于理解和写得好，而不是它是否快速地。

于 2012-12-07T18:21:10.320 回答
3

正如下面的文章所说，使用更少的参数它会表现得更好，但它对性能的影响并不大。但是你应该考虑传递一个对象。

http://www.dailyfreecode.com/forum/parameter-performance-21574.aspx

于 2012-12-07T18:14:20.480 回答
1

那么会有成本。所有这些参数都必须被压入堆栈。我不认为它会在计算能力方面造成麻烦，除非它处于一个沉重的循环中。

你对一个程序员同事生气吗？或者制作某种以编程方式创建的代码？

于 2012-12-07T18:14:04.643 回答
1

回答您的问题：不，传递 100 个参数不会对性能造成重大影响。与另一个答案不同，我建议不要传递对象。如果你这样做，代码将变得不可维护。我见过充满了没人理解的参数的地图。相反，请使用 Joshua Block 在 Effective Java（第 7 章，方法签名）中推荐的最佳实践，以将参数数量保持在合理水平。

例如：将您的方法分解为多个方法。

请参阅类似问题的答案：

将许多参数传递给方法的最佳实践？

于 2012-12-07T18:17:17.403 回答
0

我目前正在阅读题为“Java: The Good Parts”的书。它建议一般来说，传递接口是要走的路。我建议你用 100 个参数创建一个接口，然后传递它而不是传递 100 个参数。将来发生的事情会更加清楚。

就我而言，最大的成本将是维护它的麻烦。但是，如果这就是您计划做的所有事情，那么将这些参数传递一次并没有太大的区别。

于 2012-12-07T18:18:04.673 回答
0

这很难回答，大多数人发现不止少数方法参数表明存在严重问题。

但是有一些方面，当您考虑它时，也表明许多方法参数会对性能产生影响。每个方法参数都占用堆栈上的一个槽（就像局部变量一样）。就其本身而言，一个插槽基本上几乎是免费的，但是当调用你的方法怪物时，每个参数插槽也必须被填充。这意味着调用者不可避免地会进行一些读取操作来获取插槽的值，并且还会将所述值推送到堆栈中。

所以是的，每个参数都有一个很小的成本，作为第一个近似值，成本与参数的数量成线性关系。

现在，当您从某个地方提取参数值时，您实际上做的工作不仅仅是传递对所述参数的引用 - 例如，假设您有一种方法来计算矩形的面积并用 4 个参数编写它：

public int area(int x1, int y1, int x2, int y2) {
     return ....;
}

代替

public class Rectangle {
    int x1, y1, x2, y2;

    public int area() {
        return ....;
    }
}

现在在第一种情况下，您需要拉出 4 个整数并将它们推回堆栈，而要调用第二种情况，您只需拉出对矩形的引用。当然，矩形的 area() 方法仍然需要拉取其成员，但您至少保存了 3 个堆栈推送（使用 100 个参数，您可能可以保存更多）。

另外，一个有 100 个参数的方法意味着它是一个相当大的方法，否则大多数参数无论如何都不会被使用，只会浪费。大型方法表明复杂性很高，这可能会干扰 JIT 生成良好代码的能力。很难演示，但一个简单的例子就是方法内联。JIT 对内联考虑的代码量有限制，大型方法不是候选方法。在某种程度上，您可以期望 JIT 能够最好地处理常用的习惯用法（优化最常见的情况显然会带来更多的努力），并且 100 个方法参数肯定超出了常用的范围。

于 2012-12-07T18:32:59.907 回答