Question

我的问题主要是关于C#编译器如何处理小数据类型的内存分配。我知道，例如，像add这样的运算符是在int上定义的，而不是在short上，因此计算将像short是int成员一样执行。

假设如下：

There s no business logic/validation logic associated with the choice of short as a datatype
We re not doing anything with unsafe code

尽可能使用短数据类型是否会减少应用程序的内存占用？这样做是否可取？或者使用short之类的方法不值得付出努力，因为编译器分配了int32的全部内存，并在进行算术时添加了额外的强制转换。

任何关于运行时性能影响的链接都将不胜感激。

相关问题：

为什么我应该使用int而不是C中的字节或short#

整数求和蓝色，短+=短问题

Answer 1

从仅内存的角度来看，使用short而不是int会更好。原因很简单，short变量在内存中只需要int的一半大小。CLR不会在内存中将short扩展为int。

然而，这种内存消耗的减少可能会显著降低应用程序的运行时性能。所有现代CPU使用32位数字的性能都比使用16位数字要好得多。此外，在许多情况下，CLR将不得不在short和int之间转换，例如，当调用采用int参数的方法时。在采用这种方式之前，还需要考虑许多其他性能方面的因素。

我只会在您的应用程序中非常专用的位置和模块上更改这一点，并且只有当您真的遇到可测量的内存短缺时。

在某些情况下，您当然可以在不影响性能的情况下轻松地从int切换到short。一个例子是ints的巨大数组，所有这些数组也适用于shorts。

Answer 2

就内存使用而言，只有当您的程序中有这些类型的非常大的数组（或在List<；>；等数组上构建的集合），或由这些数组组成的压缩结构数组时，才有意义。总的来说，我的意思是这些阵列的总内存占用占工作集的很大百分比，占可用内存的很大百分比。至于可取性，我敢说，除非你的程序操作的数据是用short等明确指定的，或者数据量达到千兆字节，否则不建议使用短类型。

Answer 3

简而言之——是的。但是，您也应该注意内存对齐。您可以找到掌握C#结构和c#中类的内存对齐？有用

Answer 4

这取决于你用短裤做什么。此外，您是否分配了内存占用所需的那么多变量？

如果这个程序要在移动设备或内存有限的设备上使用，那么我可能会担心。然而，如今大多数机器都运行至少1-2gb的ram，并且拥有相当不错的双核处理器。此外，如今大多数移动设备正在成为野兽级的迷你电脑。如果你声明的太多以至于这种类型的机器开始失效，那么你的代码就已经有问题了。

然而，在回答这个问题时。在内存有限的机器中，如果您声明了很多4字节的变量，而只需要一个2字节的变量来填充它们，那么您可能应该使用short。

如果你预先形成复杂的计算，平方根之类的，或高价值的计算。然后，您可能应该使用具有更多字节的变量，这样就不会有丢失任何数据的风险。只要在需要的时候声明你需要什么。如果你已经用完了，就把它清零，以确保C#会清理掉，如果你担心内存限制的话。

Answer 5

当谈到机器语言时，在注册表级别，我认为最好与注册表大小保持一致，因为大多数移动和算术函数都是在注册表边界上完成的。如果机器设置了32位注册表，最好与32位对齐。如果机器有用于I/O操作的16位注册表，则最好与16位对齐，以减少移动内容时的操作次数。

友情链接