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