很久以前，我记得阅读过您应该始终使用尽可能小的类型来存储数据，但几乎我阅读的每段代码都没有这样做。他们经常到处使用 32 位整数。
我听说 32 位值的获取速度与 8 位值一样快，但处理器有一些方法可以一次获取多个较小的值。对吗？
因此，如果我使用 4 个字节而不是 4 个整数，编译器是否应该能够对此进行优化，以便将 4 个字节获取/存储在单个 32 位寄存器中？
或者这一切真的只是过早的优化，潜在的性能提升可以忽略不计？
【问题讨论】：
标签： optimization compiler-construction types processor
在 32 位 CPU 中，将四个 8 位字节打包成一个 32 位字可以提高内存访问时间，因为可以一次获取四个字节。但是，现在要操作单个字节，CPU 必须执行额外的移位和掩码等。因此，无论是将 4 个字节打包成一个字，还是将每个字节解包（每个 8 位字节使用 32 位）都有优点和缺点。
假设我们谈论的是 C 或 C++，优化编译器通常会为您做出正确的决定，但如果您必须通过自己打包到结构等中来明确控制此行为。
但是，使用与数据域匹配的类型还有其他更好的理由：清晰度、可维护性等。我认为这些在 99% 的情况下确实胜过优化问题。
【讨论】：
这取决于。如果您在具有小缓存的小型处理器上运行，那么选择最小的数据大小可能是有意义的。如果您有大量数据，例如数百万个样本，每个样本都需要 8 位精度，那么使用最小的数据大小是有意义的。在大多数其他情况下，将其留给编译器。
【讨论】：
确实是过早的优化！但是，一旦您进行优化，它也取决于您的架构。例如，在 ARM 上，内存访问必须是 32 位对齐的（有些指令可以做到这一点，但它们只是进行 32 位访问，然后在幕后进行掩码/移位）。如果您使用一个字节，编译器通常会给每个“字节”四个实际字节的 RAM，以便可以更快地访问它（更不用说如果您尝试访问未对齐的字节而没有特殊的代码来处理它们，CPU 会吓坏）。
因为它是 CPU 的首选大小，所以对所有内容都使用“int”是有争议的，但基本上，只需使用您需要的大小类型，让编译器担心优化：D
【讨论】：