我的问题主要是关于C#编译器如何处理小数据类型的内存分配。我知道，例如，像add这样的运算符是在int上定义的，而不是在short上，因此计算将像short是int成员一样执行。
假设如下：
- 选择short作为数据类型没有相关的业务逻辑/验证逻辑
- 我们没有用不安全的代码做任何事情
尽可能使用短数据类型是否会减少应用程序的内存占用？这样做是否可取？或者使用short之类的方法不值得付出努力，因为编译器分配了int32的全部内存，并在进行算术时添加了额外的强制转换。
任何关于运行时性能影响的链接都将不胜感激。
相关问题：
为什么我应该在C#中使用int而不是字节或short
整数求和蓝色，短+=短问题
从仅内存的角度来看，使用short而不是int会更好。简单的原因是short变量在内存中只需要int变量的一半大小。CLR不会将内存中的short扩展到int。
然而，这种内存消耗的减少可能会显著降低应用程序的运行时性能。所有现代CPU使用32位数字的性能都比使用16位数字要好得多。此外，在许多情况下，CLR必须在short和int之间进行转换，例如调用采用int参数的方法。在采用这种方式之前，还需要考虑许多其他性能方面的因素。
我只会在您的应用程序中非常专用的位置和模块上更改这一点，并且只有当您真的遇到可测量的内存短缺时。
在某些情况下，您当然可以在不影响性能的情况下轻松地从int切换到short。一个例子是ints的巨大阵列，所有这些也适用于shorts。
只有当您的程序中有这些类型的非常大的数组（或基于List<>等数组构建的集合），或由这些数组组成的压缩结构数组时，在内存使用方面才有意义。我所说的"大"是指这些阵列的总内存占用占工作集的很大百分比，占可用内存的很大百分比。至于可取性，我敢说，除非你的程序操作的数据是根据short等明确指定的，或者数据量达到千兆字节，否则不建议使用短类型。
简而言之-是。但是，您也应该注意内存对齐。你可以在C#中找到掌握C#结构和类的内存对齐？有用的
取决于短裤的用途。此外，您是否分配了内存占用所需的那么多变量？
如果这个程序要在移动设备或内存有限的设备上使用，那么我可能会担心。然而，如今大多数机器都运行至少1-2gb的ram，并且拥有相当不错的双核处理器。此外，如今大多数移动设备正在成为野兽级的迷你电脑。如果你声明的太多以至于这种类型的机器开始失效，那么你的代码就已经有问题了。
然而，在回答这个问题时。在内存有限的机器中，如果您声明了很多4字节的变量，而只需要一个2字节的变量来填充它们，那么您可能应该使用short。
如果你预先形成复杂的计算，平方根之类的，或高价值的计算。然后，您可能应该使用具有更多字节的变量，这样就不会有丢失任何数据的风险。只要在需要的时候声明你需要什么。如果你已经用完了，就把它清零，以确保C#会清理掉，如果你担心内存限制的话。
当谈到机器语言时，在注册表级别，我认为最好与注册表大小保持一致，因为大多数移动和算术函数都是在注册表边界上完成的。如果机器设置了32位注册表，最好与32位对齐。如果机器有用于I/O操作的16位注册表，则最好与16位对齐，以减少移动内容时的操作次数。