Question

我找到了一些关于这个问题的主题。大多数人似乎倾向于在他们的c＃代码中使用int，即使一个字节或一个smallint处理数据，除非它是一个移动应用程序。我不明白为什么。将C＃数据类型定义为数据存储解决方案中的数据类型是否更有意义？

我的前提：如果我使用类型化数据集，Linq2SQL类，POCO，我会遇到编译器数据类型转换问题，如果我不保持我的数据类型在我的层之间同步。我真的不喜欢一直在做System.Convert，因为在c＃代码中使用int更容易。我总是使用任何最小的数据类型来处理数据库和代码中的数据，以保持我的数据库接口干净。所以我敢打赌，75％的C＃代码使用byte或short而不是int，因为这就是数据库中的内容。

的可能性：这是否意味着大多数只为代码中的所有东西使用int的人也使用int数据类型作为他们的sql存储数据类型，并且可能不关心他们的数据库的整体大小，或者他们是否在适用的代码中执行system.convert？

为什么我关心：我一直在努力工作，我只想熟悉最佳实践和标准编码惯例。

Answer 1

在性能方面，几乎在所有情况下int都更快。 CPU旨在高效地使用32位值。

较短的值很难处理。例如，要读取单个字节，CPU必须读取包含它的32位块，然后屏蔽掉高24位。

要写入一个字节，它必须读取目标32位块，用所需的字节值覆盖低8位，然后再写回整个32位块。

当然，在空间方面，您可以使用较小的数据类型来节省几个字节。因此，如果您要构建一个包含几百万行的表，那么较短的数据类型可能值得考虑。（同样可能是您在数据库中使用较小数据类型的理由）

正确性，int不容易溢出。如果你认为你的值将适合一个字节，然后在未来的某个时候对代码进行一些无害的改变意味着更大的值被存储到它中会怎样？

这些是为什么int应该是所有整数数据的默认数据类型的一些原因。如果您确实想存储机器字节，则仅使用byte。如果您正在处理实际指定16位整数值的文件格式或协议或类似物，则仅使用短路。如果你只是处理整数，那就把它们整理一下吧。

Answer 2

我只迟到了6年但也许我可以帮助其他人。

以下是我将使用的一些指导原则：

如果将来有可能数据不适合，请使用较大的int类型。
如果变量用作struct / class字段，那么默认情况下它将被填充以占用整个32位，因此使用byte / int16将不会节省内存。
如果变量是短暂的（就像在函数内部那样）那么较小的数据类型将无济于事。
＆＃34;字节＆＃34;或＆＃34; char＆＃34;有时可以更好地描述数据，并且可以进行编译时间检查，以确保在发生意外时不会为其分配更大的值。例如如果使用一个字节存储月中的某一天（1-31）并尝试为其分配1000，则会导致错误。
如果变量用于大约100或更多的数组中，我会使用较小的数据类型，只要它有意义。
byte和int16数组不像int（基元）那样是线程安全的。

没有人提出的一个主题是有限的CPU缓存。较小的程序比较大的程序执行得更快，因为CPU可以在更快的L1 / L2 / L3缓存中容纳更多程序。

使用int类型可以减少CPU指令，但是它也会强制更高百分比的数据内存不适合CPU缓存。说明书执行起来很便宜。现代CPU内核每个时钟周期可以执行3-7条指令，但另一方面单个高速缓存未命中可能需要1000-2000个时钟周期，因为它必须一直到RAM。

当节省内存时，它还会导致应用程序的其余部分执行得更好，因为它不会被缓存挤出。

我使用字节数组和int数组以随机顺序访问随机数据进行了快速求和测试。

const int SIZE = 10000000, LOOPS = 80000;
byte[] array = Enumerable.Repeat(0, SIZE).Select(i => (byte)r.Next(10)).ToArray();
int[] visitOrder = Enumerable.Repeat(0, LOOPS).Select(i => r.Next(SIZE)).ToArray();

System.Diagnostics.Stopwatch sw = new System.Diagnostics.Stopwatch();
sw.Start();
int sum = 0;
foreach (int v in visitOrder)
    sum += array[v];
sw.Stop();

以下是时间结果（滴答）:( x86，发布模式，无调试器，.NET 4.5，I7-3930k）（越小越好）

________________ Array Size __________________
       10  100   1K   10K  100K    1M   10M 
byte: 549  559  552   552   568   632  3041  
int : 549  566  552   562   590  1803  4206

使用CPU上的字节随机访问1M项目，性能提升了285％！
任何低于10,000的东西都难以察觉。
int从未比字节更快。
这些值会因具有不同缓存大小的不同CPU而异。

最后一点，有时我会看一下现在的开源.NET框架，看看微软的专家是做什么的。 .NET框架使用byte / int16令人惊讶的少。我实际上找不到任何东西。

Answer 3

在存储容量方面存在显着差异之前，您必须处理几个BILLION行。假设您有三列，而不是使用字节等效的数据库类型，您使用int等效。

这给了我们每行3（列）x 3（字节额外），或每行9个字节。

这意味着，对于“几百万行”（比方说三百万行），您需要额外消耗27兆字节的磁盘空间！幸运的是，由于我们不再生活在20世纪70年代，你不必担心这一点：）

如上所述，停止微优化 - 转换为/从不同类似整数的数字类型中获得的性能将会对您造成太大影响，比带宽/磁盘空间成本要大得多，除非您处理的非常非常，非常大的数据集。

Answer 4

在大多数情况下，'不'。

除非你事先知道你要处理100万行，否则这是微观优化。

最适合Domain模型的是什么。之后，如果您遇到性能问题，请使用基准测试和配置文件来确定它们的位置。

Answer 5

并不是说我不相信乔恩格兰特和其他人，但我必须亲自看看我们的“百万行表”。该表有1,018,000。我将11个tinyint列和6个smallint列转换为int，已经有5个int＆amp; 3个小时。 4个不同的索引使用了各种数据类型的组合，但显然新索引现在都使用了int列。

进行更改只需要花费40 MB来计算没有索引的基表磁盘使用情况。当我在整体变化中添加索引时总体上只有30 mb的差异。所以我很惊讶，因为我认为索引大小会更大。

使用所有不同数据类型的麻烦值得30 MB，No Way！我要去INT土地，感谢大家让这个肛门保持程序员重新回到没有更多整数转换的直接幸福生活... yippeee！

Answer 6

如果在任何地方都使用int，则不需要转换或转换。这比使用多个整数大小节省的内存要大得多。

它只会让生活更简单。

Answer 7

.NET运行时针对Int32进行了优化。请参阅.NET Integer vs Int16?

之前的讨论

我为什么要在C＃中使用int而不是字节或short

7 个答案: