It's said that constant references within a program are replaced by the value at compile time, where as, variable references will need to be looked up at run time - making them slower.
Yeah, it sounds faster, but won't they ultimately both be locations in memory (that will have to be looked up), with the difference being that the variable can be altered?
Some machine instruction sets include instructions for which 'small' constants are part of the instruction, either explicitly or implicitly. E.g the set of 'add' instructions can include 'add immediate', where the value to be added fills out the rest of the instruction bits. In that case, the operation does not need to fetch the constant value from a separate location - it 'comes for free' during the 'add' instruction fetch. Not all constants can be handled in this manner, but a lot of the more common constants can.
Something similar has been done in certain interpreters. For example, the Pascal P-CODE interpreter implemented each instruction op-code as one byte, but all 128 of the positive byte values were interpreted as immediate loads - e.g if the next op-code was the value 0x40 (the 'space' character), then the value 0x40 was pushed onto the expression stack. The Java Virtual Machine derives (at least conceptually) from the P-CODE interpreter, and may do the same thing.
An operation like a + c can often be implemented slightly faster if c is a constant that is known to the compiler because it can be made part of the instruction. Also if a value is known to be unchanged that gives opportunities to an optimising compiler. In the extreme case, if you calculate a*c and know that c is the constant 1.0, you don't even to multiply.
There are exceptions: Some compilers seem to believe that constants are always faster. If a variable like c is used often, it gets loaded into a register and stays there. If c is a constant, the compiler loads it every single time it is used. I've had time critical code where execution time improved significantly when I convinced the compiler that a constant value might change (storing a constant into a variable didn't help because the compiler figured out the value never changed).
This is a compiler limitation. The point is: It's very hard to predict what exactly will run faster. And it can change as processors change, or as compilers change.
