This post is an addition to the previous answer from Roland Kofler in June 2016.
Execution costs should be really the vm execution costs, if I
interprete the parameter vmResult correctly. Is this maybe because a
default constructor will be called any way?
In addition to Roland:
Execution cost has everything to do with the costs for storing global variables and the runtime of the method calls.
Storing global variables seems rather expensive to me.
In the code below you see me testing the mathematical efficiency of exponentiation. All the computations together cost roughly 500.
Adding the line "result = res;" changes this from 500 to roughly 20,000 execution cost.
uint256 result;
function modPow2() returns (uint res){
res = 2341**4 % 3456;
res = res**8 % 3456;
res = res**2 % 3456;
res = res**2 % 3456;
res = res**2 % 3456;
res = res**4 % 3456;
result = res;
}
If you run this method twice in a row, it costs respectively 20,000 and then 5,000. The third time I run it, it costs 5,000 again. My guess is that changing the bit-size of the global variable result is expensive.
I tested this by resetting the value with result=0; or do result=result+1; between the runs.
Then Transaction cost has everything to do with the size of the compiled contract PLUS the execution cost. Comments don't change the transaction costs and the naming of the variables also don't. But adding a (non-called) method does.
You can call some methods within your contract and it appears that transaction cost - execution cost = constant for the compiled contract you are currently working with.