Home/ Questions/Q 8128661
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-06T07:58:39+00:00

I have the following code: char stats[109]; /* !LINE UNDER QUESTION! */ sprintf(stats, OBJECTS:\n%u/256\n

  • 0

I have the following code:

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);

Is it fine to statically allocate array of 109 chars (109 is enough for my text), or aligning the array to 128 bytes will increase performance?

I don’t care about file size and memory use, performance is important for me, my code must run at 60 FPS on old computers.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    I guess this is too much related on the hardware on which the code will run. We can think for instance of two opposite arguments to answer this, assuming there will be other variables allocated on the stack around your array:

    • if you keep the array small, it will reduce the number of cache entries used to hold all the variables frequently used.
    • if you align the size on a power of two, and the address of the array is in one register of the CPU, calculating the address of the variable just after can be easier depending on the addressing mode of the CPU. For instance, it is easier for the ARM to encode an offset like 0x12000 than 0x12001, because it is taking a bitfield and shifting it.

    The second argument seems however less relevant, as it will only impact one variable among the many you can instantiate. In any case, you will need to benchmark your code if you want to be sure.

    • 0