我应该使用byte还是int?

通常是的,32位整数的性能会稍好一点,因为它已经针对本机CPU指令进行了正确的对齐。只有在实际需要存储该大小的内容时,才应使用较小的数字类型。

您应该使用DayOfWeek枚举,除非有充分的理由不使用。

DayOfWeek day = DayOfWeek.Friday;

解释一下,因为我被否决了:

这个 正确性 你的代码几乎总是比 性能 尤其是在我们谈论这一微小差异的情况下。如果使用一个枚举或一个表示数据语义的类(无论是DayOfWeek枚举,还是另一个枚举,或加仑或英尺类)使代码更清晰或更易于维护,它将帮助您达到安全优化的程度。

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;

这不会编译,甚至看一看,很明显为什么不添加加仑到脚上 毫无意义 .

我的默认位置是尝试使用强类型向值添加约束-在这里您可以预先知道这些约束。因此,在您的示例中,最好使用 byte dayOfWeek 因为它更接近您想要的值范围。

下面是我的推理,以存储和传递一年的日期为例。年份部分-在考虑包括SQL Server日期时间的系统其他部分时,限制为1753到9999(注意c的日期时间可能范围不同!)因此A short 包含我可能的值,如果我尝试传递更大的值,编译器将在代码编译之前警告我。不幸的是,在这个特定的示例中,c datetime.year属性将返回一个int,因此,如果需要传递(例如),将强制我强制转换结果。 DateTime.Now.Year 进入我的功能。

这个起始位置是由长期数据存储的考虑因素驱动的,假设有“数百万行”和磁盘空间——尽管它很便宜(当您托管并运行SAN或类似设备时,它要便宜得多)。

在另一个数据库示例中,我将使用较小的类型(如byte(SQL Server tinyint))作为查找ID,在该类型中,我确信不会有太多的查找类型,而在ID中,可能会有更多的记录,则使用到long(SQL Server bigint)。即涵盖交易记录。

所以我的经验法则是:

1. 如果可能的话,先去寻求正确性。当然,在示例中使用dayofweek:)
2. 选择适当大小的类型,从而利用编译器安全检查,尽早给出错误;
3. …但是与极端的性能需求和简单性相抵消,特别是在不涉及长期存储的情况下,或者在我们考虑查找(低行数)表而不是事务性(高行数)表的情况下。

为了清晰起见,通过将列类型从bigint收缩为较小的类型,DB存储往往不会像预期的那样迅速收缩。这是因为对单词边界的填充以及数据库内部的页面大小问题。但是,您可能会在数据库中多次存储每个数据项,可能是通过在历史记录发生变化时存储它们,还可以保留最近几天的备份和日志备份。因此,节省您的存储需求的百分之几将长期节省存储成本。

我个人从来没有遇到过字节与整数的内存性能问题,但是我浪费了很多时间和时间来重新分配磁盘空间,让活动服务器完全停止运行,因为没有人可以监视和管理这些问题。

system.dayofweek(系统.dayofweek)

MSDN

大多数时候使用int.不是为了性能,而是为了简单。

使用一个整数。计算机内存由“字”寻址,通常是4字节长。这意味着,如果您想从内存中获取一个字节的数据,CPU必须从RAM中检索整个4字节的字,然后执行一些额外的步骤来隔离您感兴趣的单个字节。在考虑性能时,CPU检索一个完整的单词并完成它会容易得多。

实际上,在所有的现实中,你不会注意到这两者在性能方面的任何区别(除了在罕见的极端情况下)。这就是为什么我喜欢使用int而不是byte,因为你可以存储更大的数字,而不会受到任何惩罚。

就储存量而言,使用 byte 在CPU性能方面,使用 int .