我将第一次使用非常小的数字（因为在每个int中将介于1到10之间并且一次有100个这样的变量），我想知道是否有使用16位整数VS 32位时的任何显着性能差异。我的大多数用户将使用64位处理器，但有些将使用32位。
答案 0 :(得分：4)
<强> CPU
使用单个数字时，可能使用更紧凑的表示略有改进。也就是说，
ushort a;
ushort b;
// @mikez pointed a & b are promoted to int when added
// C# spec, 7.3.6.2 Binary numeric promotions
ushort result = (ushort)(a + b);
可能比
略快ulong a;
ulong b;
ulong result = a + b;
取决于您的算法。原因是当单个数字较小时，更多数据可以适合CPU缓存，最终必须将更少的数据从RAM传输到CPU。
另一方面，由于读取/写入未与64位地址边界对齐的数据，它可能稍慢。
这两个因素相互影响。测量您的用例，以便从CPU的角度来判断您是好还是坏。
在内存中
使用List<ushort>代替List<ulong>将节省75％的内存成本。 如果这可以防止交换，它将使您的应用程序受益。
在磁盘上
如果要保存到数据库，并且如果您的工作集太大而无法容纳数据库引擎可用的RAM，则使用较小的大小可能会对性能产生巨大差异，因为更多记录适合磁盘的较少扇区减少磁盘寻道时间（假设没有SSD）并增加每单位时间可通过IO通道传输的数据点数量。
<强>买者
请注意，与计算机的处理能力相比，如果非常大量为真，则所有仅都很重要。如果您有足够的RAM来将所有数据保存在内存中，则不会进行交换。如果您的数据库服务器和/或存储控制器缓存可以将您的工作集保留在内存中，那么磁盘存储大小的考虑将无关紧要。
底线
如果您要处理的值范围错误，使用较小的数据类型只会对您造成伤害，并且您突然需要更大的数据类型来保存所有值。
快速制作关键算法原型。使用ushort，uint，ulong的各种选项进行一些测量。
如果你的“100个变量”每个只包含一个数字（而不是一个包含大量数字的列表），这些都不重要。只有当你开始对你的计算机施加压力时（可能是10到100的数百万或更多的数据点，取决于你在做什么），这些优化对你的用户来说是真实的。
答案 1 :(得分：3)
如果有疑问，请测量。但除了内存消耗差异外，我怀疑你会看到什么。
答案 2 :(得分：2)
这里的答案总的来说很好，但是在.NET平台上有一个特定的考虑因素：CIL中没有8位或16位算术运算。
这意味着为了算术，所有8位和16位值都被隐式转换为32位。
ECMA Specs - Part 3 (CIL) - 第1.6节隐性论证强制