为什么我应该使底层types的Enum Int32而不是字节？
鉴于以下枚举：
public enum Operations_PerHourType : byte { Holes = 1, Pieces = 2, Sheets = 3, Strips = 4, Studs = 5 } 当我运行微软的代码分析工具时，它告诉我：
CA1028：Microsoft.Design：如果可能，使底层types的“Enums.Operations_PerHourType”System.Int32而不是“字节”。
它永远不会超过几个可能的值，所以我把它声明为一个字节。 他们为什么会推荐使用int32？ 未来可扩展性的更多价值？ 还是有性能改进？
看看MSDN的原因。
这是一个摘录：
枚举是一种定义一组相关的命名常量的值types。 默认情况下，System.Int32数据types用于存储常量值。 即使您可以更改此基础types，但对于大多数情况，这不是必需的或推荐的。 请注意，使用小于Int32的数据types不会获得显着的性能增益。 如果您不能使用默认数据types，则应使用符合公共语言系统（CLS）的整型typesByte，Int16，Int32或Int64之一来确保枚举的所有值都可以用符合CLS编程语言。
根据文档，使用一个字节代替INT32没有性能收益。 除非有理由这样做，否则他们build议不要改变它。 基本的想法是，.NET在许多情况下使用INT32进行了优化，他们select了枚举的原因。 你没有得到任何改变，所以为什么要麻烦。
http://msdn.microsoft.com/en-us/library/ms182147.aspx
这也谈到如何优化使用32位整数.NET ： .NET优化Int32
在某些情况下，缩小底层types会带来一些优势，例如性能相关，或者在连接到非托pipe代码时强制特定的内存布局。
考虑这个例子：
using System; public enum Operations_PerHourType // : byte { Holes = 1, Pieces = 2, Sheets = 3, Strips = 4, Studs = 5 } class Program { static void Main() { long before = GC.GetTotalMemory(false); var enums = new Operations_PerHourType[10000]; long after = GC.GetTotalMemory(false); Console.WriteLine(after - before); // output (byte): 12218 (I'm using Mono 2.8) // output (Int32): 40960 } }
这段代码占用了大约40KB的堆。 现在指定（取消注释）底层types为byte并重新编译。 哇。 突然我们只需要大概10 KB。
像这样压缩内存有时会使程序变慢，而不是更快，这取决于特定的访问模式和数据大小。 没有办法知道，而不是做一些测量，并试图推广到其他可能的情况。 小数据的顺序遍历通常更快。
然而，养成狭义types的习惯，因为它通常是可能的，有时甚至是关键的，这不是一个好主意。 由于周围更宽数据types的内存alignment，内存节省很less实现。 由于屏蔽填充字节所需的附加指令，性能可能会相同或稍差。
另一个答案已经说得很好，请遵循运行时优化的Int32群体，直到您不得不在应用程序中开始分析和解决真正的内存耗尽为止。
