关于做大量计算的三个问题

Three questions about doing lots of calculations

这只是一系列关于进行大量计算的问题。要么我在网上找不到答案,要么我还需要澄清。

  1. 作为方法参数传递 (float, float, float) 与数组具有三个项的 (float[]) 相比是否更快?

  2. 方法 return a float[] 与设置作为参数传递给方法的 float[] 的内容是否更快?

  3. 用实际计算替换方法调用是否更快,即 A=sum(B,C) 是否比 A=B+C 慢?假设 sum(x,y){return x+y}

编辑:

谢谢大家的回答!在我关闭这个线程之前,如果有人知道的话,我还有一个快速的问题:

  1. 如果我使用 class 一次又一次地重复计算相同的统计数据(然后将其丢弃),创建实例变量作为容器以避免连续计算会更好吗重新分配和取消分配?

1) Is it faster to pass (float, float, float) as method parameters vs (float[]) where the array has three terms?

1.) 视情况而定。如果单独的浮点数在内存中不连续,那么 float[] 可能会有所帮助。

2) Is it faster for a method to return a float[] vs setting the contents of a float[] that is passed to the method as an argument?

2.) 取决于两种情况下 float[] 是否已经存在。如果您正在创建一个新的 float[] 并将其传入,或者创建一个新的 float[] 并返回它,则成本是相同的。但是,如果在任何一种情况下您都可以以某种方式使用现有的 float[],那将会更快并且创建更少的分配。

3) Is it faster to replace method calls with the actual calculations i.e. instead of is A=sum(B,C) any slower than A=B+C? assuming sum(x,y){return x+y}

3.) 我不确定,我更像是一名 C# 程序员。我知道在 运行 C# 时 Xbox 360 使用的基本 CLR(公共语言运行时),手动计算比使用重载方法便宜得多。我不确定 Java 是否在任何平台上都有类似的问题。

Is it faster to pass (float, float, float) as method parameters vs (float[]) where the array has three terms?

这取决于。如果您手边已经有了浮点数数组,那么应该没有任何区别。如果你每次都构造数组,那将需要一些时间来分配给数组,并且可能需要一些时间来构造数组。

重要吗?如果您在连续执行几百万次的紧密循环中执行此操作,并且在您的应用程序的生命周期中多次执行,它肯定可以。

Is it faster for a method to return a float[] vs setting the contents of a float[] that is passed to the method as an argument?

如果您每次都需要为您的 return 值构造浮点数组,那么这肯定不会比在预先存在的数组中设置值更快。 仅仅是因为这两个选项都涉及设置值,并且其中一个选项具有创建新数组的额外任务。但是创建一个新数组可能真的非常快。

不过,如果您在您的应用中快速连续执行数百万次,对其进行基准测试,它可能会节省您一些时间。

Is it faster to replace method calls with the actual calculations i.e. instead of is A=sum(B,C) any slower than A=B+C? assuming sum(x,y){return x+y}

几乎不可能说。内置的 HotSpot 代码优化器非常擅长发现此类内容并为您进行优化。

如果你对此进行基准测试,请尝试使用 sum 方法 private,这将使 HotSpot 更容易决定它是否可以内联(尽管它也会自己发现这一点,如果您没有 sum 方法的任何重写实现)


这里关于基准测试的一件事是:

它现在可以帮助您的应用程序,使用您正在使用的当前版本的 VM(以及您当前的代码库)。如果您决定升级到新版本的 VM,您可能会发现性能特征发生变化,您可能需要重新优化。

所以只有当它对你的应用程序真的很重要时才去做,否则可能会浪费精力。

最好先关注您的算法及其 space 和时间复杂度;任何收获都是永远的收获。