Not only can this be a futile optimization, but you can cause integer misalignment (i.e., integers do not match 4-byte or 8-byte boundaries depending on the architecture), which can actually slow down performance. To get around this, most compilers try to align integers on most architectures, so you may not save any space at all, because the compiler adds an addition (e.g. for variables based on stack and structure elements) to correctly align large variables or structure elements which follow your 8-bit integer. Since your question looked like it was a local variable in a function and assuming that there is only one such variable and that the function is not recursive, optimization is most likely not needed, and you should just use your own integer platform size (i.e. . whole).
The optimization that you mentioned can be useful if you have a lot of instances of a certain type and want to consume less memory using 8-bit fields rather than 64-bit fields for small integers in the structure. If this is your intention, be sure to use the correct pragmas and / or compilers for your platform so that the structures are correctly packed to the smallest size. Another example where using a smaller integer size can come in handy is when arrays are involved, especially large ones. Finally, keep in mind that specifying the number of bits in a type is not portable, because the double underscore specified in it is indicated.
I can mention this, since it seems to concern only your question, but you can go even less than 8-bit ints in structures, for even smaller ranges of values than 0-255. In this case, the field bits become an option - the epitomy of micro-optimization. Do not use bit fields unless you have actually measured performance in areas of time and space and are not sure that there is significant savings. To dissuade you further, I will introduce some of the pitfalls of using them in the next paragraph.
Bit fields add extra complexity to the development process, forcing you to manually arrange structure elements to collect data by as few bytes as possible - a task that is not only complicated, but also often leads to completely unintuitive ordering of structure member variables. Modifications, additions, and deletions member variables often tend to cascade to members that follow them, which causes a maintenance problem in the future. To work around this problem, developers often insert padding and alignment bits into the structure, which complicates the process for everyone except the original code developer. Commenting out such code is no longer subtle and often becomes a necessity. There is also a problem when developers forget that they are dealing with a bit field inside the code and consider it as if it has the entire domain of its base type, which does not lead to silence and is sometimes difficult to debug under / overflow.
In accordance with the above recommendations, profile your application to see if the discussed optimization options have only your specific compilers and platform (s).