-1

我有以下代码：

char stats[109]; /* !LINE UNDER QUESTION! */
sprintf(stats,
    "OBJECTS:\n%u/256\n" \
    "BLOCKS:\n%u/" GP_ConstantExpand(Map_MaxLightmaps) "\n" \
    "QUADS:\n%u/" GP_ConstantExpand(Map_MaxLightmaps) "\n" \
    "LIGHTMAPS:\n%u/" GP_ConstantExpand(Map_MaxLightmaps) "\n" \
    "CHECKPOINTS:\n%u/256\n" \
    "HINTS:\n%u/256",
    Map_This_Header.objects, Map_This_Header.blocks, Map_This_QuadCount,
    lmapcount, Map_This_Header.checkpoints, Map_This_Header.hints);

静态分配 109 个字符的数组（我的文本 109 就足够了）是否可以，或者将数组对齐到 128 个字节会提高性能？

我不关心文件大小和内存使用，性能对我来说很重要，我的代码必须在旧计算机上以 60 FPS 运行。

4

2 回答 2

2

我想这与运行代码的硬件有太多关系。例如，我们可以考虑两个相反的参数来回答这个问题，假设在您的数组周围的堆栈上分配了其他变量：

  • 如果您保持数组较小，它将减少用于保存所有经常使用的变量的缓存条目的数量。
  • 如果将大小对齐为 2 的幂，并且数组的地址在 CPU 的一个寄存器中，则根据 CPU 的寻址模式，计算紧随其后的变量的地址会更容易。例如，ARM 编码 0x12000 之类的偏移量比 0x12001 更容易，因为它需要一个位域并对其进行移位。

然而，第二个参数似乎不太相关，因为它只会影响您可以实例化的众多变量中的一个。无论如何，如果您想确定，您需要对您的代码进行基准测试。

于 2012-06-15T12:29:59.563 回答
0

如果对齐它会提高性能，编译器应该在适当的优化级别为您对齐它。这是因为编译器可以自由地对自动变量进行排序和对齐，因为它认为合适。

通常，除非您的代码实际上需要对齐才能操作（例如，如果您将整数存储在指针字段的低位中，因此需要将实际的基指针对齐到更大的边界），您不应该将这样的假设编码到您的代码中。

于 2012-06-15T14:48:45.480 回答