So I've also run into the code size issue. I am a bit curious about what sort of data types are preferred for one's working set. (Obviously in RAM and constants we want as small as possible) My brief experimentation changing one of my types was:
type - bytes free
u8 - 427
u16 - 387
s16 - 355
u32 - 435
s32 - 435

Thus, I'd conclude that full ints are the best thing to use for all your temporary calculations - it would seem extra code has to be emitted to deal with passing around 16-bit integers.

Is this correct?

That's correct - the "native" type for the processor is 32-bits. When you use 16-bit integers, the compiler will typically generate extra instructions to sign-extend, mask, etc to enforce the limitations of 16-bits and make comparisons and other operations work correctly. Ironically, these types of processors will often handle 8-bit integers better than they handle 16-bit ones since byte operations are more common and necessary.

However, if you have large tables of integers that fall within the range of 16-bits, it's sometimes better to go ahead and store them that way, since the additional storage used by the table can exceed the savings in the instructions.

One trick some people do it simple abstract the types and once the code is done, fiddle with them to get the best storage/speed/code size tradeoff.