我记得在某处读过使用Int32更好(在性能方面),即使你只需要字节.它(仅限于)适用于您不关心存储的情况.这有效吗？
例如,我需要一个可以保存一周的变量.我
int dayOfWeek;
要么
byte dayOfWeek;
编辑:伙计们,我知道DayOfWeek枚举.问题是关于其他事情.
Mik*_*keP 20
通常是的,32位整数的性能稍好一些,因为它已经针对本机CPU指令正确对齐.当您确实需要存储该大小的内容时,您应该只使用较小的数字类型.
kyo*_*ryu 12
你应该使用DayOfWeek枚举,除非有充分的理由不这样做.
DayOfWeek day = DayOfWeek.Friday;
要解释一下,因为我被投票了:
代码的正确性几乎总是比性能更重要,特别是在我们谈论这个小差异的情况下.如果使用枚举或表示数据语义的类(无论是DayOfWeek枚举,还是其他枚举,或Gallons或Feet类)使您的代码更清晰或更易于维护,它将帮助您达到可以达到的程度安全优化.
int z;
int x = 3;
int y = 4;
z = x + y;
那可能会编译.但是没有办法知道它是否正在做任何有意义的事情.
Gallons z;
Gallons x = new Gallons(3);
Feet y = new Feet(4);
z = x + y;
这不会编译,甚至看着它显然为什么不 - 将Gallons添加到Feet 是没有意义的.
使用 int。计算机内存通过“字”寻址，通常为 4 个字节长。这意味着，如果您想从内存中获取一个字节的数据，CPU 必须从 RAM 中检索整个 4 字节字，然后执行一些额外的步骤来隔离您感兴趣的单个字节。关于性能，CPU 会更容易检索整个单词并处理它。
实际上，在所有现实中，就性能而言，您不会注意到两者之间有任何差异（除非在罕见的极端情况下）。这就是为什么我喜欢使用 int 而不是 byte，因为你可以存储更大的数字而几乎没有任何损失。
我的默认位置是尝试使用强类型向值添加约束-在此预先知道这些约束。因此，在您的示例中，最好使用byte dayOfWeek它，因为它更接近您的期望值范围。
这是我的理由；以存储和传递日期的年份部分为例。年份部分-当考虑系统的其他部分（包括SQL Server DateTimes）时，限制为1753到9999（请注意C＃的DateTime可能范围是不同的！）因此，a short涵盖了我可能的值，并且如果我尝试传递更大的值，编译器会在代码编译之前警告我。不幸的是，在此特定示例中，C＃DateTime.Year属性将返回一个int值-因此如果我需要将例如传递DateTime.Now.Year到函数中，则迫使我强制转换结果。
此开始位置是由长期数据存储的考虑决定的，假设存储空间为“数百万行”-即使它很便宜（在托管和运行SAN或类似产品时便宜很多）。
在另一个数据库示例中，我将使用较小的类型，例如字节（SQL Server tinyint）作为查找ID，我确信不会有太多的查找类型，直到长（SQL Server bigint）用于查找ID的地方。更多记录。即涵盖交易记录。
所以我的经验法则：
为了清楚起见，通过将列类型从bigint缩减为较小的类型，数据库存储往往不会像您期望的那样迅速收缩。这既是因为要填充单词边界，又是因为数据库内部存在页面大小问题。但是，您可能会通过将历史记录更改时存储历史记录，并保留备份和日志备份的最后几天来在数据库中多次存储每个数据项。因此，节省百分之几的存储需求将可以长期节省存储成本。
我从没有亲身经历过字节与整数的内存性能问题，但是我却浪费了数小时和数小时的时间来重新分配磁盘空间，并使活动服务器完全停顿，因为没有人可以监视和处理这样的事情。