Using different numeric variable types

Question

Im still pretty new so bear with me on this one, my question(s) are not meant to be argumentative or petty but during some reading something struck me as odd.

Im under the assumption that when computers were slow and memory was expensive using the correct variable type was much more of a necessity than it is today. Now that memory is a bit easier to come by people seem to have relaxed a bit. For example, you see this sample code everywhere:

for (int i = 0; i < length; i++)

int? (-2,147,483,648 to 2,147,483,648) for length? Isnt byte (0-255) a better choice?

So Im curious of your opinion and what you believe to be best practice, I hate to think this would be used only because the acronym "int" is more intuitive for a beginner...or has memory just become so cheap that we really dont need to concern ourselves with such petty things and therefore we should just use long so we can be sure any other numbers/types(within reason) used can be cast automagically?

...or am Im just being silly by concerning myself with such things?

Answer 1

Generally memory is cheap these days, since you don't have to worry about it you can concern yourself with more important programming details. Think of it like managing memory, the less of it you have to do the more productive you are overall. Ultimately it has to do with the level of abstraction, if you don't need to control how all the cogs and wheels work then it is best not to tinker with them.

In practice you will generally always use either ints or longs (if you need the extra size). I wouldn't concern myself with anything less these days unless I was optimizing. And remember the golden rule of optimization Don't optimize unless you have to. Write your code first then optimize if needed.

Another similar situation is when designing a database schema. I often see people design a schema an allow only what they need on NVARCHAR columns. To me this is ridiculous because it is a variable length column so you are not wasting space, and by given yourself plenty of room you avoid problems down the road. I once worked for a company that had internal logging on the website; once I upgraded to IE8 the website start crashing. After some investigation I found that the logging schema only allowed 32 characters for the browser id string, but when using IE8 (with Vis Studio and other extensions) the browser id string grew beyond 32 and caused a problem which prevented the website from working at all. Sure there could have been more stringent length checking and better error handling on the part of the developer in charge of that, but by allowing for 256 instead of 32 would not only have prevented the crash, but we wouldn't be truncating the data in the db.

I am not suggesting that you use strings, and Int64 for all your datatypes (no more than I suggest you set all your sql columns to NVARCHAR(4000)) because you lose readability. But choose an appropriate type and give yourself lots of padding.

Answer 2

Using a variable that is smaller than the CPU native register size, can actually result in more code being emitted.

As another poster said, don't worry about micro-optimisiations. If you have a performance problem, first profile. 9 times out of 10 your performance problem won't be where you thought it was.

Answer 3

Luca Bolognese posted this in his blog.

Here's the relevant part:

• Use int whenever your values can fit in an int, even for values which can never be negative
• Use long when your values can't fit in an int.
• Byte, sbyte, short, ushort, uint, and ulong should only ever be used for interop with C code. Otherwise they're not worth the hassle.

Answer 4

No, I don't think you are being silly, this is a great question!

My opinion is that using strongly typed variables is a best practice. In your example, the variable i is always positive so it could be unsigned int.

When developing programs we need to consider: 1) size 2) speed and 3) the cost of the programmer. These are not mutually exclusive, sometimes we trade off size for speed and of course those best able to do this (great programmers) cost more than beginners.

Also remember what is fastest on computer X may be slower on computer B. Is it a 16 bit, 32 bit, 64 bit etc. operating system? In many cases we want a variable to be aligned on word boundaries for speed so that using variables smaller than a word does not end up saving any space.

So it is not necessary best to use the smallest possible variable, but it is always best practice to make an informed choice as to the best type to use.

Answer 5

Local variables like loop indexes are cheap. How many frames are you going to have on the stack at a time? Fifty? A hundred? A thousand? What's the overhead of using a thousand int counters instead of a thousand byte counters? 3K? Is saving 3K worth the rework when it turns out that a couple of those arrays need more than 255 elements?

If you're allocating tens of millions of these things, then squeezing the bit count may make sense. For locals, it's a false economy.

Another factor is what the type communicates to your readers. For better or for worse, people put very little interpretation on an int; but when they see a byte they'll tend to interpret it as something specifically byte-oriented, such as binary data coming off a stream, maybe pixels, or a stream that needs to be run through an encoder to turn it into a string. Using a byte as a loop counter will throw many readers of your code off their stride as they stop and wonder, "Wait, why is this a byte instead of an int?"

Answer 6

Considering this note may help you:

The runtime optimizes the performance of 32-bit integer types (Int32 and UInt32), so use those types for counters and other frequently accessed integral variables. For floating-point operations, Double is the most efficient type because those operations are optimized by hardware.

source: MCTS Self-Paced Training Kit (Exam 70-536): Microsoft® .NET Framework Application Development Foundation, Second edition

Note: I think this is OK for x86 machines, but for x64 I don't know.