Do this:
In any sketch change a single variable type between a byte and integer.
I get 8 bytes difference after verifying it. In my case from 3320 bytes down to 3312 bytes. I thought an integer is only two bytes so code size should go up to 3313 from byte to integer?
You're mixing program memory and SRAM. A byte takes up half the space as an int in SRAM, but handling of the two in terms of number of instructions may vary.
This is my gut feeling based on working at the assembler level of other processors. (Theory is similar, details may be different...)
Much like Arrch said, using byte instead of int would reduce the SRAM (not sketch size BTW) usage by 1 byte for each variable, but remember the uP at the heart of these Arduinos is an 8bit chip. The accumulator (and related other registers) are only 1 byte long. Meaning it can really only operate on one byte at a time. In order to work on two bytes at a time there are extra commands needed to swap the two bytes in and out of the accumulator, track carry bits, etc. I haven't studied the datasheet for the 328 to see if there are special purpose registers that are longer, but even the amount of arguments for the opcodes for those registers are usually greater than a simple accumulator action.
The Arduino is an 8-bit processor. A byte is 8 bits, an integer is 16 bits.
An 8 bit system adding 2 8 bit values can just add the values. For it to work in 16 bits it has to go through a lot of operations to split the values down into 8 bit values and operate on them individually carrying over values from low to high bytes.
It all takes more instructions, which increases the amount of Flash uses. It also increases the RAM usage by 1 byte.
Ah! Thank you.
It of course makes sense about the extra operations to use an integer. I suspect a "float" will be much worse, but not tested yet! Now I understand why a short piece of code using a float, is so much bigger than using integers in much longer code. A valuable lesson indeed.
Bergie:
Ah! Thank you.
It of course makes sense about the extra operations to use an integer. I suspect a "float" will be much worse, but not tested yet! Now I understand why a short piece of code using a float, is so much bigger than using integers in much longer code. A valuable lesson indeed.
Yes, floating point operations are incredibly slow and cumbersome. That is why computers have included a hardware Floating Point Unit (FPU) to do the work for them. These have been around for many many years, but only really started being included by default with the 486 DX range of chips. Others had add-on chips that could be connected up (like the 68881 for Amiga / early MAC computers using the Motorola 68000 family of CPUs, etc). Now they are standard in all CPUs in use in "normal" computers. Theoretically it is perfectly feasible to add an FPU as an external component to an MCU, but I'm not aware of any with "simple" interfaces that would be easy to wire up, and for the cost it'd be better to start off with an MCU with an FPU in it already.
FWIW, majenko's comment made me wonder if anyone had attached a FPU coprocessor to an Arduino. A quick Google search for "Arduino fpu" found this in the playground: http://playground.arduino.cc/code/fpu
So it's there if anyone really wants to play with it.
The pinout of that chip looks eerily familiar...
Could it be a dsPIC33FJ in disguise ...? 
Sembazuru:
FWIW, majenko's comment made me wonder if anyone had attached a FPU coprocessor to an Arduino. A quick Google search for "Arduino fpu" found this in the playground: Arduino Playground - HomePage
So it's there if anyone really wants to play with it.
Or if you are going to be doing a lot of floating point, buy an Arm processor that has floating point. Unfortunately, neither the Due nor the Teensy 3.0 use a chip with FP on it, so at present you would have to change how you program your system. I don't know if the pcdunio (cortex-a8) has floating point or not. Rasberry PI does have FP.