Why wear shorts?

In general there is no reason to use short in applications, especially in .NET.

A case to use is if you have a large volume large numeric data within the range that fits in a short (-32768 to 32767). At a very large volume, decreasing from 4 to 2 bytes can give some edge. But notice that this volume really needs to be very big indeed. It is very rare to be necessary. And even though the volume is large you also have to have the need (not having enough memory to use int ). Otherwise, it's micro-optimization that is not worth the effort.

Another point is that this memory usage optimization is valid when you will practically only use short data in your structured data. If the information is in more complex structures, where the short field is only a part of the memory consumption, especially if the structure is of a reference type (objects allocated in heap ), the gain certainly will not help much in memory consumption.

Depending on platform and implementation of JITter may even worsen performance using short . There is usually a gain when the data size equals the word size of the processor. But do not try to use information about implementation, it can change without warning. If there is a very large volume of data that needs to be handled intensely the most common is that it has some gain mainly because of the ability to store more (double) elements in cache using a short than a int . >

You may have losses, in some cases, also because you have to make unnecessary conversions. Much of .NET is better prepared to work with int . But the opposite can make short more interesting. If you know you are going to use many methods that primarily work with short their use may prevent conversions, but are rare methods.

A typical case for avoiding conversions is when working with interoperability with external code that expects a short , mostly with C / C ++ code, managed or not. Interoperability is the main case for which short was created in .NET .

The Maniero's answer already gives a great overview, I just want to complement the following part:

  The most common if there is a very large volume of data that needs to be handled intensively is that it has some more gain by the ability to store more cached elements by using a short than a int .

In general, the influence of good caching on a system's performance is something to not be underestimated. Often a lot of attention is paid to local performance (casting) and forgetting the overall performance (in a miss cache ), several cycles are wasted - more than the overhead of an extra statement or two, depending on the case).

None of this contradicts the above-mentioned answer: only if the volume of data is large is there an advantage (although perhaps it disagrees with what would be "very" large). Also, it is quite different to have, for example, an array of objects:

class MeuObjeto {
    Foo foo;
    Bar bar;
    Baz baz;
    short s;
}
MeuObjeto[] array = new MeuObjeto[10000];

Or an array of short s:

short[] array = new short[10000];

In the first case, space savings are minimal - even if the objects are in contiguous memory positions (depending on the case, they may not be) - and that is if memory alignment does not eliminate this space gap. The use of short instead of int will not have a significant impact on cache misses , so casting overhead will have no positive counterpart .

In the second case, the story is another: It will take you twice as long to have a cache miss if you are accessing these elements sequentially, compared to an array of int . Even for random hits, the chance of the data you want to be in the cache is twice as high. So even though each individual operation is a little less efficient, the cycles you "save" by avoiding missions can compensate for - making the entire operation faster.

(In any case, the advice remains to avoid premature optimizations / micro optimizations)

Do not slow down, since the CPU is still 64-bit, it still has instructions for dealing with smaller numeric types than the native.

The .net char for example has 16 bits, which is equivalent to a short / ushort.

The real advantage I see in using the smaller integer types would be to save memory in the case of needing an array with millions of items in memory ... or even billions.

Apart from this, it is more practical to use the type int itself.

The short type guarantees at least 16 bits - is not synonymous with int16_t.

I only see usage for it when you need to interact with a value or structure that is also short such as some hardware table, device driver, or low-level API. For example, on a TCP / IP connection the port is unsigned short ( link )

There is also a great deal going on with data coming from the network, usually in conjunction with htons (). When dealing with network, it is best to use the guaranteed size types, type int16_t or uint16_t, which guarantee the exact size in bits.

  

As far as I understand (and correct me if I'm mistaken), it's faster to work with an integer the size of the processor architecture in most cases, due to CPU optimizations.

Actually, defining variables of type short or char is a bit of a waste, since these variables will live in a register where they fit much more bits. In general, short or char is used for data stored in memory, where the size of the register does not matter. The time it takes to transfer shorts from memory to a register is the same time it takes to read an int, but the shorts vector will spend half the space that the int vector.