C# .NET 整数与 Int16？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/129023/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
.NET Integer vs Int16?
提问by Matias Nino
I have a questionable coding practice.
我有一个可疑的编码实践。
When I need to iterate through a small list of items whose count limit is under 32000, I use Int16for my ivariable type instead of Integer. I do this because I assume using the Int16is more efficient than a full blown Integer.
当我通过它的数量限制是根据项目的小单子需要遍历32000，我用Int16我的我的变量类型，而不是Integer。我这样做是因为我假设使用Int16的不是一个完整的更有效率Integer。
Am I wrong? Is there no effective performance difference between using an Int16vs an Integer? Should I stop using Int16and just stick with Integerfor all my counting/iteration needs?
我错了吗？使用 anInt16和 an之间没有有效的性能差异Integer吗？我应该停止使用Int16并坚持Integer满足我所有的计数/迭代需求吗？
采纳答案by hurst
According to the below reference, the runtimeoptimizes performance of Int32and recommends them for counters and other frequently accessed operations.
根据下面的参考，运行时优化了Int32 的性能，并为计数器和其他经常访问的操作推荐它们。
From the book: MCTS Self-Paced Training Kit (Exam 70-536): Microsoft? .NET Framework 2.0—Application Development Foundation
来自书中：MCTS 自定进度培训套件（考试 70-536）：Microsoft？.NET Framework 2.0——应用程序开发基础
Chapter 1: "Framework Fundamentals"
Lesson 1: "Using Value Types"
第 1 章：“框架基础”
第 1 课：“使用值类型”
Best Practices: Optimizing performance with built-in types
The runtime optimizes the performance of 32-bit integer types (Int32 and UInt32), so use those types for counters and other frequently accessed integral variables.
For floating-point operations, Double is the most efficient type because those operations are optimized by hardware.
最佳实践：使用内置类型优化性能
运行时优化了 32 位整数类型（Int32 和 UInt32）的性能，因此将这些类型用于计数器和其他经常访问的整数变量。
对于浮点运算，Double 是最有效的类型，因为这些运算是由硬件优化的。
Also, Table 1-1 in the same section lists recommended uses for each type. Relevant to this discussion:
此外，同一部分中的表 1-1 列出了每种类型的推荐用途。与本次讨论相关：
- Int16 - Interoperation and other specialized uses
- Int32 - Whole numbers and counters
- Int64 - Large whole numbers
- Int16 - 互操作和其他特殊用途
- Int32 - 整数和计数器
- Int64 - 大整数
回答by Nils Pipenbrinck
The opposite is true.
事实正好相反。
32 (or 64) bit integers are faster than int16. In general the native datatype is the fastest one.
32（或 64）位整数比 int16 快。通常，本机数据类型是最快的一种。
Int16 are nice if you want to make your data-structures as lean as possible. This saves space and may improve performance.
如果您想让您的数据结构尽可能精简，则 Int16 是不错的选择。这可以节省空间并可以提高性能。
回答by Curt Hagenlocher
Int16 may actually be lessefficient because the x86 instructions for word access take up more space than the instructions for dword access. It will depend on what the JIT does. But no matter what, it's almost certainly not moreefficient when used as the variable in an iteration.
Int16 实际上可能效率较低，因为用于字访问的 x86 指令比用于双字访问的指令占用更多空间。这将取决于 JIT 的作用。但无论如何，当用作迭代中的变量时，它几乎肯定不会更有效。
回答by 17 of 26
Never assume efficiency.
永远不要假设效率。
What is or isn't more efficient will vary from compiler to compiler and platform to platform. Unless you actually tested this, there is no way to tell whether int16 or int is more efficient.
什么更有效，什么不是更有效将因编译器和编译器和平台而异。除非您实际对此进行了测试，否则无法判断 int16 或 int 是否更有效。
I would just stick with ints unless you come across a proven performance problem that using int16 fixes.
除非您遇到使用 int16 修复的经过验证的性能问题，否则我会坚持使用 int。
回答by Dana
I can't imagine there being any significant performance gain on Int16 vs. int.
我无法想象 Int16 与 int 有任何显着的性能提升。
You save some bits in the variable declaration.
您在变量声明中保存了一些位。
And definitely not worth the hassle when the specs change and whatever you are counting cango above 32767 now and you discover that when your application starts throwing exceptions...
当规格改变时绝对不值得麻烦，无论你计算什么，现在都可以超过 32767 并且你发现当你的应用程序开始抛出异常时......
回答by Russ
Any performance difference is going to be so tiny on modern hardware that for all intents and purposes it'll make no difference. Try writing a couple of test harnesses and run them both a few hundred times, take the average loop completion times, and you'll see what I mean.
在现代硬件上，任何性能差异都将非常小，以致于所有意图和目的都没有区别。尝试编写几个测试工具并运行它们几百次，取平均循环完成时间，你就会明白我的意思。
It might make sense from a storage perspective if you have very limited resources - embedded systems with a tiny stack, wire protocols designed for slow networks (e.g. GPRS etc), and so on.
如果您的资源非常有限，那么从存储的角度来看这可能是有意义的——带有小堆栈的嵌入式系统、专为慢速网络（例如 GPRS 等）设计的有线协议，等等。
回答by Mark Cidade
Use Int32 on 32-bit machines (or Int64 on 64-bit machines) for fastest performance. Use a smaller integer type if you're reallyconcerned about the space it takes up (may be slower, though).
在 32 位机器上使用 Int32（或在 64 位机器上使用 Int64）以获得最快的性能。如果您真的担心它占用的空间，请使用较小的整数类型（虽然可能会更慢）。
回答by Leon Tayson
There is no significant performance gain in using a data type smaller than Int32, in fact, i read somewhere that using Int32 will be faster than Int16 because of memory allocation
使用小于 Int32 的数据类型没有显着的性能提升，事实上，我在某处读到，由于内存分配，使用 Int32 将比 Int16 快
回答by Alex Lyman
You should almost alwaysuse Int32or Int64(and, no, you do not get credit by using UInt32or UInt64) when looping over an array or collection by index.
在按索引循环数组或集合时，您几乎应该总是使用Int32or Int64（并且，不，您不会通过使用UInt32or获得荣誉UInt64）。
The most obvious reason that it's less efficient is that all array and collection indexes found in the BCL take Int32s, so an implicit cast is alwaysgoing to happen in code that tries to use Int16s as an index.
它效率较低的最明显原因是 BCL 中找到的所有数组和集合索引都采用Int32s，因此在尝试使用s 作为索引的代码中总是会发生隐式转换Int16。
The less-obvious reason (and the reason that arrays take Int32as an index) is that the CIL specification says that all operation-stack values are eitherInt32or Int64. Every time you either load or store a value to any other integer type (Byte, SByte, UInt16, Int16, UInt32, or UInt64), there is an implicit conversion operation involved. Unsigned types have no penalty for loading, but for storing the value, this amounts to a truncation and a possible overflow check. For the signed types everyload sign-extends, and every store sign-collapses (and has a possible overflow check).
的不太明显原因（以及阵列采取的原因Int32作为指标）是，CIL说明书说，所有的操作栈的值是任一Int32或Int64。每次任一负荷或值存储到任何其他整数型（Byte，SByte，UInt16，Int16，UInt32，或UInt64），有涉及的隐式转换的操作。无符号类型对加载没有惩罚，但对于存储值，这相当于截断和可能的溢出检查。对于有符号类型，每个加载符号扩展，每个存储符号折叠（并且有可能的溢出检查）。
The place that this is going to hurt you most is the loop itself, not the array accesses. For example take this innocent-looking loop:
这会伤害你最深的地方是循环本身，而不是数组访问。以这个看起来很无辜的循环为例：
for (short i = 0; i < 32000; i++) {
...
}
Looks good, right? Nope! You can basically ignore the initialization (short i = 0) since it only happens once, but the comparison (i<32000) and incrementing (i++) parts happen 32000 times. Here's some pesudo-code for what this thing looks like at the machine level:
看起来不错，对吧？不！您基本上可以忽略初始化 ( short i = 0) 因为它只发生一次，但是比较 ( i<32000) 和递增 ( i++) 部分发生了 32000 次。下面是一些伪代码，用于说明这件事在机器级别上的样子：
Int16 i = 0;
LOOP:
Int32 temp0 = Convert_I16_To_I32(i); // !!!
if (temp0 >= 32000) goto END;
...
Int32 temp1 = Convert_I16_To_I32(i); // !!!
Int32 temp2 = temp1 + 1;
i = Convert_I32_To_I16(temp2); // !!!
goto LOOP;
END:
There are 3conversions in there that are run 32000times. And they could have been completely avoided by just using an Int32or Int64.
那里有3 次转换，运行了32000次。只需使用Int32or就可以完全避免它们Int64。
Update: As I said in the comment, I have now, in fact written a blog post on this topic, .NET Integral Data Types And You
更新：正如我在评论中所说，实际上我现在已经写了一篇关于这个主题的博客文章，.NET Integral Data Types And You
回答by Jon Adams
The others here are correct, only use less thanInt32 (for 32-bit code)/Int64 (for 64-bit code) if you need it for extreme storage requirements, or for another level of enforcement on a business object field (you should still have propery level validation in this case, of course).
这里的人是正确的，只用不到的Int32（32位码）/的Int64（64位码），如果你需要它极端的存储需求，或对业务对象场执法的另一个层面（你应该当然，在这种情况下仍然具有属性级别验证）。
And in general, don't worry about efficiency until there is a performance problem. And in that case, profile it. And if guess & checking with both ways while profiling doesn't help you enough, check the IL code.
而且一般来说，在出现性能问题之前不要担心效率。在这种情况下，分析它。如果在分析时用两种方式进行猜测和检查对您的帮助还不够，请检查 IL 代码。
Good question though. You're learning more about how the compiler does it's thing. If you want to learn to program more efficiently, learning the basics of IL and how the C#/VB compilers do their job would be a great idea.
好问题。您将更多地了解编译器的工作方式。如果您想更有效地学习编程，学习 IL 的基础知识以及 C#/VB 编译器如何完成它们的工作将是一个好主意。
