Question

I have some values on my functions that are < 10, normally. So,if I use __int8_t instead of int to store this values is useless effort of optimization?

Answer 1

Not only can this be a useless optimization, but you may cause integer misalignment (i.e., integers not aligned to 4-byte or 8-byte boundaries depending on the architecture) which may actually slow performance. To get around this, most compilers try to align integers on most architectures, so you may not be saving any space at all, because the compiler adds padding (e.g., for stack based variables and struct members) to properly align larger variables or struct members that follow your 8-bit integer. Since your question looked like it was regarding a local variable in a function and assuming that there was only one such variable and that the function was not recursive, the optimization is most likely unnecessary and you should just use the platform native integer size (i.e., int).

The optimization you mentioned can be worthwhile if you have very many instances of a particular type and you want to consume less memory, by using 8-bit fields instead of say 64-bit fields for small integers in a struct. If this is your intention, be sure to use the correct pragmas and/or compiler switches for your platform, so that structs get properly packed to the smallest size. Another instance where using a smaller integer size can come in handy is when arrays, especially large ones, are involved. Finally, keep in mind that specifying the number of bits in the type is non-portable, as the leading double underscore in its name indicated.

I hazard to mention this, since it appears to only be tangentially related to your question, but you can go even smaller than 8-bit ints in structs, for even smaller ranges of values than 0-255. In this case, bit fields become an option – the epitomy of micro-optimization. Don’t use bit fields unless you have actually measured performance in the time and space domains and are sure that there are significant savings to be had. To disuade you further, I present some of the pitfalls of using them in the following paragraph.

Bit fields add more complexity to the development process by forcing you to manually order struct members to pack data into as few bytes as possible – a task that is not only arduous, but also often leads to a completely unintuitive struct member variable ordering. Changes, additions and deletions of member variables often tend to cascade to the members that follow them causing a maintenance problem down the road. To get around this problem, developers often stick padding and alignment bits into the struct, complicating the process further for all but the original developer of the code. Commenting such code stops being a nicety and often becomes a necessity. There is also the problem of developers forgetting that they are dealing with a bit field within the code and treating it as if it had the entire domain of its underlying type, leading to no end of silent and sometimes difficult to debug under/overflows.

Given the above guidelines, profile your application to see whether the optimizations just discussed make sense for your particular compiler(s) and platform(s).