java - 在java中，使用byte或short而不是int和float而不是double更有效吗？

Question

我注意到我总是使用 int 和 doubles，无论数字需要多大或多小。那么在java中，使用byte是否更高效？或 short而不是 int和 float而不是 double ?

所以假设我有一个包含大量整数和 double 的程序。如果我知道这个数字合适，是否值得将我的整数更改为字节或短裤？

我知道 java 没有无符号类型，但如果我知道这个数字只是正数，我还能做些什么吗？

我所说的高效主要是指处理。我假设如果所有变量都是一半大小，那么垃圾收集器会快得多，并且计算也可能会更快一些。 (我想因为我正在使用 android，所以我也需要有点担心 ram)

(我假设垃圾收集器只处理对象而不是原始对象，但仍会删除废弃对象中的所有原始对象，对吧？)

我用我拥有的一个小型 android 应用程序进行了尝试，但并没有真正注意到有什么不同。 (虽然我没有“科学地”测量任何东西。)

我认为它应该更快更高效是不是错了？我不想经历并改变一个庞大的程序中的所有内容，以发现我浪费了我的时间。

当我开始一个新项目时，是否值得从头开始？ (我的意思是我认为每一点都会有所帮助，但如果是这样的话，为什么似乎没有人这样做。)

Answer 1

Am I wrong in assuming it should be faster and more efficient? I'd hate to go through and change everything in a massive program to find out I wasted my time.

简答

是的，你错了。在大多数情况下，它在使用的空间方面差别不大。

不值得尝试优化...除非您有明确的证据表明需要优化。如果您确实需要特别优化对象字段的内存使用，您可能需要采取其他(更有效的)措施。

更长的答案

Java 虚拟机使用偏移量(实际上)是 32 位原始单元大小的倍数来模拟堆栈和对象字段。因此，当您将局部变量或对象字段声明为(例如)byte 时，变量/字段将存储在 32 位单元格中，就像 int 一样。

这有两个异常(exception):

• long 和 double 值需要 2 个原始 32 位单元
• 原始类型数组以打包形式表示，因此(例如)字节数组每个 32 位字包含 4 个字节。

因此 可能 值得优化 long 和 double ...以及大型基元数组的使用。但一般不会。

^{理论上，JIT 可能能够优化这一点，但实际上我从未听说过有这样的 JIT。一个障碍是 JIT 通常在创建正在编译的类的实例之后才能运行。如果 JIT 优化了内存布局，你可以有两个(或更多)同一个类的对象“风格”......这将带来巨大的困难。}

---

重温

查看@meriton 答案中的基准测试结果，似乎使用 short 和 byte 而不是 int 会导致乘法性能下降.事实上，如果你孤立地考虑这些操作，惩罚是巨大的。 (你不应该孤立地考虑它们......但这是另一个话题。)

我认为解释是 JIT 可能在每种情况下都使用 32 位乘法指令进行乘法运算。但在 byte 和 short 的情况下，它执行 extra 指令将中间 32 位值转换为 byte或 short 在每个循环迭代中。 (理论上，这种转换可以在循环结束时完成一次......但我怀疑优化器是否能够解决这个问题。)

无论如何，这确实指向另一个问题，即切换到 short 和 byte 作为优化。它可能会使性能更差 ...在算术和计算密集型算法中。

---

次要问题

I know java doesn't have unsigned types but is there anything extra I could do if I knew the number would be positive only?

没有。无论如何，不​​是在性能方面。 (在 Integer、Long 等中有一些方法可以将 int、long 等作为无符号处理。但这些并没有带来任何性能优势。这不是他们的目的。)

(I'd assume the garbage collector only deals with Objects and not primitive but still deletes all the primitives in abandoned objects right? )

正确。对象的字段是对象的一部分。当对象被垃圾收集时，它就会消失。同样，当收集阵列时，阵列的单元格就会消失。当字段或单元格类型是原始类型时，值将存储在字段/单元格中......它是对象/数组的一部分......并且已被删除。