4.5.6 What are the Speed vs. Size Tradeoffs?

Microchip's dsPIC architecture can efficiently process both 16-bit and 32-bit data. It is often less run-time efficient to use a value type smaller than the native word size of the selected dsPIC DSC device as the compiler may need to extend the value to use it. There are times when this will save data space, but not always. See the items below to help make your choice faster, smaller, or both.

Array index variables and pointer offsets should always be defined as an integer sized type; size_t is an appropriately-sized native type for efficiency. A different sized integer type will require the compiler to do a conversion at run-time.
Automatic variables (function local variables) will often be allocated into a register at compile time. A register is a minimum of native word size wide, so using a smaller type can require the compiler to generate extra code. Therefore, unless 8-bit overflow rules are required, use native word size types instead. Also, the stack has alignment restrictions, making stack accesses for smaller type objects less efficient.
Argument transmission (parameter passing) either happens in registers or on the stack. Reduce the chance of generating conversions by avoiding the use of smaller than native word size objects.
Objects that are defined at File scope, or function static scope, will consume less space if defined as 8-bit typed objects. Be aware that data sections are aligned to native word size, so using named sections, or one of the other attributes that might require a new section, may not provide the data size savings that are desired.
MPLAB XC-DSC is free to reorder objects in File scope or automatic scope, but it is not allowed to re-order structure members. Unless a pre-defined interface is being conformed to, try to allocate structure members to group similarly-sized objects together, with bit-fields especially being grouped together. This will reduce the number padding-bytes that may be inserted to maintain alignment requirements.