Michelson gas cost optimizations: any techniques, patterns and rules of thumb

Question

Gas cost is an important topic in smart contract development. We want to maintain the costs as low as possible to allow for more operations in a block. There is a handy gas consumption reference, but it is already over a year old (there were lots of gas optimizations in Delphinet so the example calculation is probably out of date) and the rules are quite complicated such that it might be hard to keep all of them in mind.

Questions for experienced teams and individuals that write Michelson or designing programming languages that compile to Michelson:

1. What are you doing to reduce gas costs?

2. Are there certain instructions you avoid? For example I have heard that DIP is expensive operation, that leads me to believe it would be better to do a combination of DUP, SWAP and DIG.

3. What techniques are you using to analyze gas costs and determine if your optimization is truly better? Do to the stack nature of Michelson it can be expensive (time wise) to reorganize code.

4. When you have multiple pieces of data you need to alter (for example you want to do something like x + y * x - z then send it to another contract), do you start with an ideal stack order in mind or do you make something work then try to reorganize it later.

5. Finally, any patterns you have discovered would be helpful.

Answer 1

What are you doing to reduce gas costs?

The first thing to do is to do algorithmic optimisation, without worrying about Michelson's own constraints.

Then, to make additional savings, lower level optimisations can be done :

• organise the stack so as to reduce the number of stack operations,

• In a complex contract where the optimisation of one entry point will often be to the detriment of the others, the gas cost of the entry points that will be used most must be minimised.

• The organisation of the entry points in the parameter must be constructed in such a way that the most used entry points are more easily accessible: e.g. (or (or a b) (or c (or d e)) makes sense if a b and c are used at approximately equal frequency, if this is not the case and a is used more often, or a (or b c) (or d e)) will be more relevant.

Are there certain instructions you avoid? For example I have heard that DIP is expensive operation, that leads me to believe it would be better to do a combination of DUP, SWAP and DIG.

I have not heard that DIP is particularly expensive, however it is rarely effective to replace a single instruction with a series of instructions.

It is unlikely that such a sequence would be more gas efficient than using DIP, as this would imply a problem in the gas model and in this case would be amended in the future.

for example this sequence :{DUG 2; ADD; SWAP}; is more expensive than this one : DIP {ADD}.

you can test with the instruction tezos-client run script <contract_name>.tz on storage <storage> and input <parameter> --trace-stack.

Keep in mind that micro-optimisations must be avoided because the gas cost of instructions is likely to change with amendments, especially if those instructions are too expensive.

What techniques are you using to analyze gas costs and determine if your optimization is truly better?

When the client executes, the cost of gas execution is indicated, so to see if one set of instructions is better than another, simply make a minimum contract that successively contains both and compare the gas costs.

When you have multiple pieces of data you need to alter (for example you want to do something like x + y * x - z then send it to another contract), do you start with an ideal stack order in mind or do you make something work then try to reorganize it later.

It is certainly preferable to plan in advance how access to the elements will be done, however, it may happen that optimizations are found during the coding.

Answer 2

You may find this article useful: https://medium.com/tqtezos/how-to-minimize-transaction-costs-of-tezos-smart-contracts-9962347faf64