c# - 内存中的字节与字节数组

Question

下面的代码使用了 1 个字节的内存。

byte[] n = new byte[] { 10, 20, 30, 40 }; //memory looks like this 10 | 20 | 30 | 40

与下面这段使用 4 字节内存的代码相比。

byte n1 = 10; // memory looks like this | 10 | 0 | 0 | 0 | 20 | 0 | 0 | 0 | 30 | 0 | 0.....
byte n2 = 20;
byte n3 = 30;
byte n4 = 40;

这是在 Visual Studio 2012 + 2010 中测试的，我认为现代编译器应该为我做优化？如果放置间距真的更快，这样字节 secret 地变成一个非功能性的 int 比它为什么不对数组做同样的事情，并且如果字节数组每个值占用 4 个字节从而呈现整个字节数组会因此变得更快byte 在 32 位/64 位机器上完全没用的目的？总结一下:为什么编译器以这两种不同的方式分配内存，哪一种方式效率低下？第 2 部分如果将字节存储在实际的连续字节 block 中非常低效，那么在 32 位/64 位机器上字节的实际用途是什么，因为当您单独声明字节时 VS 拒绝这样做。

Answer 1

我假设这里确实有两个问题:

为什么编译器不把四个byte打包成一个Int32

局部变量通常不针对存储进行优化，而是针对访问速度进行优化。由于访问单个未对齐字节的速度有时在单个指令中是不可能的，并且，until recently (2009), is an order of magnitude slower与对齐地址相比，编译器作者通常使用对齐宽度作为合理的权衡。

除此之外，.Net Framework 不是针对 x86 而是针对公共(public)语言基础结构虚拟机的。 CLI 规范必须支持最小公分母，IA64 和 ARM 不支持非 QWORD 对齐的内存访问。为此，CLI 堆栈“只能存储至少 4 个字节宽的值”(P.330)。

他们为什么要这样做？我可以想象潜在或实际的性能提升会超过内存使用量的增加。鉴于 64 functional locals 的额外限制在任何给定的范围内，都应该强烈希望(超出良好的设计)将给定范围内的变量数量保持在较小的范围内。因此，净开销限制为 192 字节，这相当于我的系统中额外使用了 0.0000002% 的内存。

请记住，如果您正在访问一个字节数组，您实际上是在存储一个指针——它是内存地址的宽度(4 或 8 个字节)并直接访问内存。您正在管理哪个字节是哪个字节的语义，并承担这种复杂性。

如何以紧凑的形式存储内容以最小化内存使用

正如您所指出的，如果您的数据是大量字节，请使用字节数组来避免开销。如果您的数据是不同类型的，请使用允许访问打包数据的众多类之一(BinaryReader、BinaryWriter、BitConverter、unsafe code、structs with the StructLayout.Pack field set 都浮现在脑海中).

如果你有大量的数据，使用 Memory Mapped Files使用固定的布局结构来最小化内存使用，同时仍然允许数据集大于机器中的内存量。它比正常的内存访问更难吗？是的，是的——但优化是管理内存使用、速度和程序员劳动的平衡行为。最便宜的通常是内存。

或者，花几百美元买足够的 ram，这无关紧要。 32 GB(newegg 上 240 美元)在大多数情况下允许相当多的不在乎。