我应该使用最小的类型吗？

Question

很久以前我记得读过你应该总是使用尽可能小的类型来存储你的数据，但我读过的几乎每一段代码都没有这样做。它们经常在整个地方使用32位整数。

我听说过32位值的提取速度与8位值一样快，但处理器可以通过某种方式同时获取几个较小的值。对吧？

因此，如果我使用4个字节而不是4个整数，编译器是否应该能够对其进行优化，以便在单个32位寄存器中获取/存储4个字节？

或者所有这些都只是过早优化而潜在的性能提升可以忽略不计？

Answer 1

确实过早优化！但是，一旦优化，它还取决于您的架构。例如，在ARM上，内存访问必须是32位对齐的（某些指令可以执行此操作，但它们只执行32位访问，然后在后台进行掩码/移位）。如果你使用一个字节，编译器通常会给每个'字节'四个实际字节的RAM，这样可以更快地访问它（更不用说你会试图访问未对齐的字节，而没有特殊的代码来处理它们）。 / p>

有一个参数是使用'int'来表示所有内容，因为它是CPU的首选大小，但基本上，只需使用所需大小的类型，让编译器担心优化：D

Answer 2

这取决于。如果您在具有小缓存的小型处理器上运行，那么选择最小的数据大小可能是有意义的。如果您有大量数据，例如每个需要8位精度的数百万个样本，那么使用最小的数据大小是有意义的。在大多数其他情况下，请将其留给编译器。

Answer 3

在32位CPU中，将4个8位字节打包成32位字可以缩短内存访问时间，因为可以一次取出4个字节。但是，现在要操纵单个字节，CPU必须执行额外的移位和放大。因此，无论是将4个字节打包成一个字，还是将每个字节解压缩（每个8位字节使用32位）都有利有弊。

假设我们正在谈论C或C ++，优化编译器通常会为您做出正确的决定，但如果您必须自己打包到结构中，则可以明确地控制此行为。

但是，还有其他更好的理由可以使用与您的数据域相匹配的类型：清晰度，可维护性等。我认为这些在99％的时间里都胜过优化问题。