我的函数有一些值通常小于 10。那么,如果我使用 __int8_t 而不是 int 来存储这个值是无用的优化努力吗?
2 回答
这不仅可能是无用的优化,而且您可能会导致整数未对齐(即整数未对齐到 4 字节或 8 字节边界,具体取决于架构),这实际上可能会降低性能。为了解决这个问题,大多数编译器尝试在大多数架构上对齐整数,因此您可能根本不会节省任何空间,因为编译器添加了填充(例如,用于基于堆栈的变量和结构成员)以正确对齐更大的变量或结构成员跟随你的 8 位整数。由于您的问题看起来像是关于函数中的局部变量并假设只有一个这样的变量并且该函数不是递归的,因此优化很可能是不必要的,您应该只使用平台本机整数大小(即,诠释)。
如果您有很多特定类型的实例并且您希望通过使用 8 位字段而不是 64 位字段用于结构中的小整数来消耗更少的内存,那么您提到的优化可能是值得的。如果这是您的意图,请务必为您的平台使用正确的编译指示和/或编译器开关,以便将结构正确打包到最小大小。另一个使用较小整数大小可以派上用场的例子是涉及数组,尤其是大数组时。最后,请记住,指定类型中的位数是不可移植的,正如其名称中的前导双下划线所示。
我冒昧地提及这一点,因为它似乎只与您的问题相关,但您可以在结构中使用比 8 位整数更小的值,甚至比 0-255 更小的值范围。在这种情况下,位域成为一种选择——微优化的缩影。不要使用位域,除非您已经在时间和空间域中实际测量了性能并且确定可以节省大量成本。为了进一步劝阻您,我在下一段中介绍了使用它们的一些陷阱。
位字段通过强制您手动排序结构成员以将数据打包到尽可能少的字节中,从而增加了开发过程的复杂性——这项任务不仅艰巨,而且通常会导致结构成员变量排序完全不直观。成员变量的更改、添加和删除通常会级联到跟随它们的成员,从而导致维护问题。为了解决这个问题,开发人员经常将填充和对齐位粘贴到结构中,这使得除了代码的原始开发人员之外的所有人的过程更加复杂。评论这样的代码不再是一件好事,而且经常成为一种必要。还有一个问题是开发人员忘记了他们正在处理代码中的一个位字段,并将其视为拥有其底层类型的整个域,
鉴于上述指导方针,分析您的应用程序以查看刚刚讨论的优化是否对您的特定编译器和平台有意义。
它不会节省时间,但如果你有一百万个这样的东西,它将节省 3mb 的空间(这可能会节省时间)。