我一直在寻找,我还没有真正想出答案.
当我在内存有限的嵌入式设备上编程时,我通常习惯使用最小的积分/浮点类型来完成这项工作,例如,如果我知道计数器总是在0到255之间,我将它声明为uint8_t.
但是,在内存受限较少的环境中,我习惯只使用int来处理所有内容,按照Google C++ Styleguide.当我查看现有代码时,通常会以这种方式完成.
要明确的是,我得到了这样做的理由,(Google非常好地解释了这一点),但我并不清楚第一种方式背后的理由.
在我看来,即使在不关心内存使用的系统上,减少程序的内存占用也会对整体速度有利,因为从逻辑上讲,较少的整体数据意味着它可以更多地适应cpu缓存.
然而,使问题复杂化的是编译器将自动填充数据并将其与边界对齐,以便可以在单个总线周期中获取数据.我想,那么,它归结为编译器是否足够聪明,比如两个32位整数,并将它们组合在一个64位块中,而不是单独填充每一个到64位.
我想cpu本身是否可以利用它还取决于其确切的内部结构,但优化内存大小提高性能的想法,特别是在较新的处理器上,可以从gcc的-0s选项上的Linux内核relied for awhile这一事实得到证明.为了整体性能提升.
如果为了可移植性而编写“实际代码”,那么int是一个很好的默认选择.
无论是否为可移植性而编写,许多程序只能在具有足够内存资源的主机上运行,并且int类型可以表示所需的值范围.这意味着没有必要担心内存使用(例如,根据需要支持的特定值范围优化变量的大小),程序才能正常工作.
“有限内存”的编程当然很常见,但通常不是为什么编写大多数代码的原因.相当多的现代嵌入式系统具有足够的内存和其他资源,因此并不总是需要这些技术.
为你所谓的“有限内存”编写的许多代码实际上并不需要.有一点,程序员了解更多,大量开始沉迷于过早优化 – 担心性能或内存使用,即使没有证明他们需要这样做.虽然由于真正的需要,肯定会为“有限的内存”编写大量代码,但由于过早的优化,会编写更多这样的代码.
