So, if I (as the programmer) know that my value will never exceed a small number (say 100) because it is really just a counter-controlled loop or whatever, may I use short or char instead of int for the minute memory savings?

  • 8
    Be aware that many variables (and temporary values) in programs never occupy any memory at all, or rather occupy registers which are of fixed size anyway (erasing any size difference by rounding up to the register size).
    – user7043
    Commented Aug 6, 2014 at 18:03

3 Answers 3


You can, and this will likely work. As FrustratedWithFormsDesigner mentioned you will need to be sure of bounds checking.

Another important factor is that as delnan said registers are fixed size. But using them as a smaller type may mean using different, less-efficient instructions if the variable's size is not the computer's word size.

Most of the time there is not much to be gained from using variable sizes smaller than the machine's word size. Embedded systems may benefit, and if a file format specifies specific field sizes then of course use those. Another thing to keep in mind is memory alignment, a 16 bit variable may be aligned on a 32 or 64 bit memory boundary with unused space between variables. Or it may not. Or it may be a compiler flag.

Edit: the comments brought up a good point. Even with a 64 bit word size, int is still likely 32 bits (C/C++, desktop platforms). The reasons are historical and out of context here. However, a modern 64 bit CPU such as the Intel Core i7 is heavily optimized for 32 and 64 bit arithmetic. Any CPU should be fast when using ints the same size as its native word size. However, there is a lot of 32 bit software out there that these CPUs need to be able to run and run well. Working with ints smaller than 32 bits may or may take a performance hit, as you are now outside the realm of what the CPU is optimized for. In practice I would expect any performance hit to be minimal, and the memory difference would be negligible as well. File this one under "premature optimization."

  • Interesting. So since the Linux command getconf WORD_BIT returns 32 on mine, does that mean I should just use int? Commented Aug 6, 2014 at 19:01
  • 1
    Depends on the language and platform. C and C++ define ranges for their data types, although in practice on a desktop OS int is 32 bits. Even on a 64 bit OS/CPU that is acceptable, a 32 bit int is still widely used and works well even in 64 bit programs. As I said in my answer, there is not much if any gain from going under 32 bit for integers.
    – user22815
    Commented Aug 6, 2014 at 19:05
  • 1
    @floopdagoop it depends on the language, as Snowman said. Most have "int" default to 32 bit as it's the standard, but you can usualyl specific int16/32/64 when defining the variable. Each of these types will block off that much memory, which is "inefficient" for memory purposes, but telling the processor to hack out chunks of memory that are not it's standard size can take a bit of extra time. You just need to measure you need for extra memory with your need for faster performance. It's all about economy of scale at that point.
    – JMD
    Commented Aug 6, 2014 at 19:11
  • @JMD The 32 bit integer is so common that Java I believe makes this a standard size for all int and smaller types. Even declaring a byte variable, the JVM will still allocate 32 bits of the heap while only utilizing the first 8 bits. The reason for this is performance I would imagine.
    – maple_shaft
    Commented Aug 7, 2014 at 11:15
  • @maple_shaft it appears that Java uses 32 bit chunks of memory for stack variables, which explains why small primitives still use 32 bits. Arrays of primitives are different since an array will likely (but not necessarily) be allocated in TLS or the heap.
    – user22815
    Commented Aug 7, 2014 at 15:26

I suppose you could. Of course, if you do that you should also include code that validates your variable so that if an input is greater than 100, you get a sensible error message. And it's also a good idea to add comments to explain why you're using char instead of int (if that's what you end up doing). It might not be obvious to everyone. Are you working in an environment where memory is so tight that this will make a significant difference to your program? Are you doing this for educational reasons?

  • I'm currently just learning as hobby, though I do want to go to college for CS. I'm sure on any modern system, extracting the 3-byte difference between char and int is practically meaningless, but I do like the idea of efficiency. Commented Aug 6, 2014 at 18:59
  • @floopdagoop: I think the only place that you might see a significant difference would be on some sort of embedded system with very limited memory, and an architecture that would best be able to take advantage of this sort of coding. Commented Aug 6, 2014 at 19:03

Yes This is especially useful in for loops. People often just use int, or allow var to determine what the variable type should be. This is inefficient (but not terribly so), but for people like me who like to get every ounce of performance and are just tickled pink by using the most perfect datatype for a situation, this is awesome.

for(SByte i = 0; i <= 10; i++)

SByte allows -128 to 127. I love this little datatype because it saves on memory and is the most appropriate datatype for the situation where warranted.

However, integer, in some languages, is the fastest datatype for arithmetic operations, even when it is way to large of a container for what you need.

Arithmetic operations are faster with integral types than with other data types. They are fastest with the Integer and UInteger types in Visual Basic. 1 (msdn.com)

So in loops, yes, use this. When doing arithmetic, however, air on the side of caution and use an int unless you research the language you are using first to see what the fastest type is.

--Adding another example I gave in the comments--

You have a class that has a 100 ints in it, but none of the ints will ever go above a value of 10. Every time you create an object of that class you are blocking off 32 bits per int creating 32*100=3200 bits. If you replaced those ints with sBytes you are now blocking off 8*100=800. You are saving 2400 bits for use anywhere else.

  • I call BS on the loop being faster. At best, it uses the same registers and operations and comes out equally fast; at worst it has to do some sign extensions and winds up ever so slightly slower. Please give evidence of your assertion.
    – user7043
    Commented Aug 6, 2014 at 18:25
  • Never said it was faster. Please read before calling BS and looking like a tool.
    – JMD
    Commented Aug 6, 2014 at 18:26
  • 1
    Let us continue this discussion in chat.
    – user7043
    Commented Aug 6, 2014 at 18:50
  • 1
    This is not especially useful in for loops. Assuming it has an actual effect on the memory used in compiled code, you end up saving a number of bytes that you can literally count on one hand. Commented Aug 6, 2014 at 19:56
  • 1
    @JMD I'm not taking issue with your answer's "Yes", I'm taking issue with your answer's "This is especially useful in for loops". Commented Aug 6, 2014 at 20:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.