.NET Integer vs Int16?

Question

I have a questionable coding practice.

When I need to iterate through a small list of items whose count limit is under 32000, I use Int16 for my i variable type instead of Integer. I do this because I assume using the int16 is more efficient than a full blown Integer.

Am I wrong? Is there no effective performance difference (however minute) between using an Int16 vs an Integer? Should I stop using Int16 and just stick with Integer for all my counting/iteration needs? (VB OR C#)

Thanks in advance for any guidance!

Answer 1

The opposite is true.

32 (or 64) bit integers are faster than int16. In general the native datatype is the fastest one.

Int16 are nice if you want to make your data-structures as lean as possible. This saves space and may improve performance.

Answer 2

Int16 may actually be less efficient because the x86 instructions for word access take up more space than the instructions for dword access. It will depend on what the JIT does. But no matter what, it's almost certainly not more efficient when used as the variable in an iteration.

Answer 3

Never assume efficiency.

What is or isn't more efficient will vary from compiler to compiler and platform to platform. Unless you actually tested this, there is no way to tell whether int16 or int is more efficient.

I would just stick with ints unless you come across a proven performance problem that using int16 fixes.

Answer 4

I can't imagine there being any significant performance gain on Int16 vs. int.

You save some bits in the variable declaration.

And definitely not worth the hassle when the specs change and whatever you are counting can go above 32767 now and you discover that when your application starts throwing exceptions...

Answer 5

Assumption: Count limit under 32000.

If you really want to be efficient[1] use UInt16 (0 to 65535)

If you want to be CLS Compliant, use int(i.e. Int32)

[1] I haven't seen the IL

Answer 6

Any performance difference is going to be so tiny on modern hardware that for all intents and purposes it'll make no difference. Try writing a couple of test harnesses and run them both a few hundred times, take the average loop completion times, and you'll see what I mean.

It might make sense from a storage perspective if you have very limited resources - embedded systems with a tiny stack, wire protocols designed for slow networks (e.g. GPRS etc), and so on.

Answer 7

Use Int32 on 32-bit machines (or Int64 on 64-bit machines) for fastest performance. Use a smaller integer type if you're really concerned about the space it takes up (may be slower, though).

Answer 8

There is no significant performance gain in using a data type smaller than Int32, in fact, i read somewhere that using Int32 will be faster than Int16 because of memory allocation

Answer 9

You should almost always use Int32 or Int64 (and, no, you do not get credit by using UInt32 or UInt64) when looping over an array or collection by index.

The most obvious reason that it's less efficient is that all array and collection indexes found in the BCL take Int32s, so an implicit cast is always going to happen in code that tries to use Int16s as an index.

The less-obvious reason (and the reason that arrays take Int32 as an index) is that the CIL specification says that all operation-stack values are either Int32 or Int64. Every time you either load or store a value to any other integer type (Byte, SByte, UInt16, Int16, UInt32, or UInt64), there is an implicit conversion operation involved. Unsigned types have no penalty for loading, but for storing the value, this amounts to a truncation and a possible overflow check. For the signed types every load sign-extends, and every store sign-collapses (and has a possible overflow check).

The place that this is going to hurt you most is the loop itself, not the array accesses. For example take this innocent-looking loop:

for (short i = 0; i < 32000; i++) {
    ...
}

Looks good, right? Nope! You can basically ignore the initialization (short i = 0) since it only happens once, but the comparison (i<32000) and incrementing (i++) parts happen 32000 times. Here's some pesudo-code for what this thing looks like at the machine level:

  Int16 i = 0;
LOOP:
  Int32 temp0 = Convert_I16_To_I32(i); // !!!
  if (temp0 >= 32000) goto END;
  ...
  Int32 temp1 = Convert_I16_To_I32(i); // !!!
  Int32 temp2 = temp1 + 1;
  i = Convert_I32_To_I16(temp2); // !!!
  goto LOOP;
END:

There are 3 conversions in there that are run 32000 times. And they could have been completely avoided by just using an Int32 or Int64.

Update: As I said in the comment, I have now, in fact written a blog post on this topic, .NET Integral Data Types And You

Answer 10

According to the below reference, the runtime optimizes performance of Int32 and recommends them for counters and other frequently accessed operations.

From the book: MCTS Self-Paced Training Kit (Exam 70-536): Microsoft® .NET Framework 2.0—Application Development Foundation

Chapter 1: "Framework Fundamentals"
Lesson 1: "Using Value Types"

Best Practices: Optimizing performance with built-in types

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.

Also, Table 1-1 in the same section lists recommended uses for each type. Relevant to this discussion:

• Int16 - Interoperation and other specialized uses
• Int32 - Whole numbers and counters
• Int64 - Large whole numbers