假设我正在像20/30对象一样循环,或者在我处理较小数字的任何其他情况下,使用short而不是int是一个好习惯吗?
我的意思是为什么这不常见:
for(short i=0; i<x; i++)
Method(array[i]);
是因为性能提升太低了吗?
由于
答案 0 :(得分:12)
“使用short而不是int是一个好习惯吗?”
首先,这是一种微观优化,无法达到预期效果:提高速度或效率。
第二:不,不是,CLR内部仍然使用32位整数(Int32)来执行迭代。基本上,它在JIT编译期间将short转换为Int32以用于计算目的。
第三:数组索引是Int32,当用作数组索引器时,迭代short变量自动转换为int32。
如果我们采用下一个代码:
var array = new object[32];
var x = array.Length;
for (short i = 0; i < x; i++)
Method(array[i]);
并且反汇编它,您可以清楚地看到00000089 inc eax
在机器级别,32位寄存器用于迭代变量(eax),接下来被截断为16位0000008a movsx eax,ax
所以有使用short32反对使用int32没有任何好处,实际上由于需要执行额外的指令可能会有轻微的性能损失。
00000042 nop
var array = new object[32];
00000043 mov ecx,64B41812h
00000048 mov edx,20h
0000004d call FFBC01A4
00000052 mov dword ptr [ebp-50h],eax
00000055 mov eax,dword ptr [ebp-50h]
00000058 mov dword ptr [ebp-40h],eax
var x = array.Length;
0000005b mov eax,dword ptr [ebp-40h]
0000005e mov eax,dword ptr [eax+4]
00000061 mov dword ptr [ebp-44h],eax
for (short i = 0; i < x; i++)
00000064 xor edx,edx
00000066 mov dword ptr [ebp-48h],edx
00000069 nop
0000006a jmp 00000090
Method(array[i]);
0000006c mov eax,dword ptr [ebp-48h]
0000006f mov edx,dword ptr [ebp-40h]
00000072 cmp eax,dword ptr [edx+4]
00000075 jb 0000007C
00000077 call 657A28F6
0000007c mov ecx,dword ptr [edx+eax*4+0Ch]
00000080 call FFD9A708
00000085 nop
for (short i = 0; i < x; i++)
00000086 mov eax,dword ptr [ebp-48h]
00000089 inc eax
0000008a movsx eax,ax
0000008d mov dword ptr [ebp-48h],eax
00000090 mov eax,dword ptr [ebp-48h]
00000093 cmp eax,dword ptr [ebp-44h]
00000096 setl al
00000099 movzx eax,al
0000009c mov dword ptr [ebp-4Ch],eax
0000009f cmp dword ptr [ebp-4Ch],0
000000a3 jne 0000006C
答案 1 :(得分:1)
是的,性能差异可以忽略不计。但是,对于int来说,short使用16位而不是32位,因此可以想象如果处理足够小的数字,可能需要使用short。
答案 2 :(得分:1)
通常,使用与处理器的字大小匹配的数字比不匹配的数字快。另一方面,short使用的内存空间少于int。 如果你的内存空间有限,可以选择使用short;但我个人在撰写c#应用程序时从未遇到过这样的事情。
答案 3 :(得分:0)
int
使用32位内存,short
使用16位,byte
使用8位。如果您只是在循环使用20/30个对象并且您担心内存使用情况,请改用byte
。
今天的机器很少需要满足这个级别的内存使用量,尽管你可能会认为在任何地方使用int
只是懒惰。就个人而言,我尝试始终使用使用最少内存的相关类型。
http://msdn.microsoft.com/en-us/library/5bdb6693(v=vs.100).aspx