当我们知道循环的确切数量时,使用byte / short作为计数器变量是一个好习惯吗? 例如
for (byte i = 1; i <= 26; i++)
vs
for (short i = 1; i <= 26; i++)
VS
for (int i = 1; i <=26; i++)
答案 0 :(得分:8)
简答:否。
答案很长:不,因为CPU针对整数运算进行了优化。如果你使用字节或短路,CPU通常必须通过应用位掩码将其转换为整数并返回。
答案 1 :(得分:7)
更有可能是混乱而不是有用。大多数开发人员希望看到int
值,并且CPU中只有32位或64位寄存器,因此它不会改变程序的工作方式或执行方式。
有许多选项可以使用并且对您的程序无害但是您需要考虑那些必须阅读并稍后了解它的可怜的开发人员,这可能是您从现在开始的6个月。 ;)
即使性能更快,除非速度更快,否则也不值得做出这样的改变。考虑一下这种变化。
for (byte i = 1; i <= 200; i++)
或
for (byte i = 1; i <= x; i++)
你可能会认为这很好,因为200&lt; 2 ^ 8它编译得很好,但它实际上是一个无限循环。
你必须问这个问题;如果你以后增加引入bug的风险,它必须多快?
通常答案是它必须以我测量的方式(不仅仅是你改变的位)使我的整个程序明显更快而且我必须要求它显着更快。
答案 2 :(得分:2)
当您对short或byte变量执行某些操作时,必须将其显式地转换回java中所需的类型。因此,最好使用int代替byte和short。 示例:
short s = 0;
s= (short) (s+10);
如果你没有将它强制转换为int,它将抛出编译时错误:Type mismatch: cannot convert from int to short
所以最好使用int。
答案 3 :(得分:1)
不,不是。
字节和短变量此时为32位/ 64位大小,VM针对int进行了优化。
“过早优化是所有邪恶的根源”
答案 4 :(得分:0)
如果您的方案中数据类型的范围不超过。两种情况都没有问题。
但int
是首选。
答案 5 :(得分:0)
我没有足够的重复评论。 你以前问过这个问题。 看看这个链接 If I use byte instead int, will my loop iterate faster?
答案 6 :(得分:0)
它也占用一行内存,通常为4或8个字节。 这意味着内存使用也不会受到限制。
此外,如果您的系统使用碎片化算法将内存行分配给这些值的部分寻址,那么其寻址算法将耗费大量资金!
答案 7 :(得分:-1)
作为一个起点,使用int
这可能是架构的原生,并且在将i
与其他位片进行比较时,您将避免可能的隐式转换。所以我的赌注是,byte
和short
最终会慢慢。
远程可行的优化是使用++i
而不是i++
,因为前者永远不会比后者慢。 (从概念上讲,i++
必须返回一个副本,即使它被优秀的java编译器优化了。)