byte/short Vs int 作为循环计数器变量答案

【问题标题】：byte/short Vs int as for loop counter variablebyte/short Vs int 作为循环计数器变量
【发布时间】：2013-12-04 08:57:08
【问题描述】：

当我们知道循环的确切数量时，使用 byte/short 作为计数器变量是一种好习惯吗？例如

for (byte i = 1; i <= 26; i++)

对

for (short i = 1; i <= 26; i++)

对

 for (int i = 1; i <=26; i++)

【问题讨论】：

【解决方案1】：

它更容易令人困惑而不是有用。大多数开发人员希望看到 int 值，而您的 CPU 中只有 32 位或 64 位寄存器，因此它不会改变您的程序的工作或执行方式。

有许多可行的方法对您的程序无害，但您需要考虑可怜的开发人员，他们必须在以后阅读并理解它，这可能是 6 个月后的您。 ;)

即使性能更快，也不值得做出这样的改变，除非它明显更快。考虑一下这种变化。

for (byte i = 1; i <= 120; i++)

或

for (byte i = 1; i <= x; i++)

你可能认为这很好，因为 200

你必须提出问题；如果您增加以后引入错误的风险，它必须要快多少？

通常的答案是它必须以我测量的方式（不仅仅是你改变的一点）使我的整个程序显着更快，而且我必须需要它显着更快。

【讨论】：

@Masud 正确，这就是我的意思，它仍然编译得很好；）
@MaheshVarma 通常知道更改何时可以提高性能以及何时应避免使用此类技巧。在这种情况下，它没有帮助，但其他技巧可以在其他情况下提供帮助，但如果不需要它们，您仍然可以避免它们。
这不能回答问题。字节类型不足以满足预期循环的数量。
@iheanyi 你说得对，200 对于有符号字节来说太大了。

【解决方案2】：

简答：不。

长答案：不，因为 CPU 已针对整数运算进行了优化。如果您使用字节或短字节，CPU 必须经常将其转换为整数并返回，通常是通过应用位掩码。

【讨论】：

【解决方案3】：

当您对短变量或字节变量执行某些操作时，您必须将其显式类型转换回 java 中所需的类型。所以最好用int代替byte和short。示例：

short s = 0;
s= (short) (s+10);

如果不将其类型转换为 int，则会引发编译时错误：Type mismatch: cannot convert from int to short 所以最好使用 int。

【讨论】：

我肯定不会对它们进行任何操作@nishu
内部 short 和 byte 将仅被视为 int。为了准备就绪，您可以使用短或字节，没关系。我不确定它是否会有任何性能问题。您在循环中每次都在增加 short 和 byte，因此您正在执行操作。看起来类型转换是在内部 ++ 运算符的情况下完成的。 i++ 可以改写为 i = (short)(i+1);

【解决方案4】：

不，不是。

byte 和 short 变量此时为 32bit/64bit 大小，VM 针对 int 进行了优化。

“过早的优化是万恶之源”

【讨论】：

我要为这条评论打分，因为它针对的是 JVM，而不是 CPU 架构。当我针对应该保护我免受此类事情影响的虚拟机进行编程时，我不关心底层架构是不是很奇怪？我最初的直觉是无论如何都要这样做，但我训练自己认为 Java 就是计算机。

【解决方案5】：

如果数据类型的范围不超过您的方案。两种情况都没有问题。

但int 是首选。

【讨论】：

【解决方案6】：

它还需要一行内存，通常为 4 或 8 个字节。这意味着也不会优化内存使用。

此外，如果您的系统使用碎片算法将内存行划分为这些值的部分寻址，则其寻址算法将花费很多！

【讨论】：

【解决方案7】：

作为一个起点，使用int，这可能是架构的本机，在将i 与其他零碎进行比较时，您将避免可能的隐式转换。所以我敢打赌byte 和short 最终都会变慢。

更可爱的优化是使用++i 而不是i++，因为前者永远不会比后者慢。（概念上i++ 必须返回一个副本，即使它会被一个好的 java 编译器优化出来）。

【讨论】：