56

给定以下枚举：

public enum Operations_PerHourType : byte
{
    Holes = 1,
    Pieces = 2,
    Sheets = 3,
    Strips = 4,
    Studs = 5
}

当我运行 Microsoft 代码分析工具时，它告诉我：

CA1028：Microsoft.Design：如果可能，将基础类型设为“Enums.Operations_PerHourType”System.Int32 而不是“byte”。

它永远不会有超过几个可能的值，所以我将它声明为一个字节。为什么他们会推荐使用 int32？未来可扩展性的更多价值？还是有性能提升？

4

3 回答 3

40

看看MSDN上的原因。

这是一段摘录：

枚举是一种值类型，它定义了一组相关的命名常量。默认情况下，System.Int32 数据类型用于存储常量值。即使您可以更改此基础类型，但在大多数情况下都不需要也不建议这样做。请注意，使用小于 Int32 的数据类型不会获得显着的性能提升。如果不能使用默认数据类型，则应使用符合公共语言系统 (CLS) 的整数类型之一，Byte、Int16、Int32 或 Int64，以确保枚举的所有值都可以以符合 CLS 的方式表示编程语言。

于 2012-04-18T19:52:59.270 回答
27

在某些特定情况下，缩小底层类型会带来一些优势，例如与非托管代码接口时与性能相关或强制特定内存布局。

考虑这个样本：

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
    }
}

此代码消耗大约 40 KB 的堆。现在指定（取消注释）底层类型byte并重新编译。哇。突然间，我们只需要大约 10 KB。

像这样压缩内存有时可能会使程序变慢，而不是更快，这取决于特定的访问模式和数据大小。除了进行一些测量并尝试推广到其他可能的情况外，没有办法确定。较小数据的顺序遍历通常更快。

然而，仅仅因为它通常是可能的并且有时是关键的而养成指定窄类型的习惯并不是一个好主意。由于周围更广泛的数据类型的内存对齐，内存节省很少实现。由于需要额外的指令来屏蔽填充字节，因此性能要么相同，要么稍差。

正如另一个答案已经说得很好，跟随Int32运行时优化的人群，直到您必须开始分析和解决应用程序中的实际内存消耗。

于 2012-04-18T21:23:03.693 回答
21

根据文档，使用字节而不是 INT32 不会提高性能。除非有理由这样做，否则他们建议不要更改它。基本思想是 .NET 针对在许多场景中使用 INT32 进行了优化，他们选择它作为枚举是有原因的。通过更改它，您不会在您的场景中得到任何东西，所以为什么要麻烦。

http://msdn.microsoft.com/en-us/library/ms182147.aspx

这还讨论了如何优化 .NET 以使用 32 位整数：.NET Optimized Int32

于 2012-04-18T19:53:06.587 回答