Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Enable reordering of methods ids in generated evm code. #4858
Each method has an ID. When a call to a smart contract is made the first step is to find the correct method based on that ID. Currently solidity generates code that checks all method ids that are available in alphabetical order. To allow the development of gas optimised contracts it would be useful if this order could be adjusted.
To optimise gas we were discussing in our project to rename a method from
In the described case the method id for
As we know that nearly all transactions interacting with out smart contract will use this method we would love to be able to adjust the order in which the method id's are checked.
A method annotated with
The annotation could also specify an order (
This should not break any current behaviour.
generates the following method jumps:
I think this is an optimiser level problem (well, code generator to be precise, but from the users' perspective it is optimiser).
Therefore I would suggest not to pollute the language syntax with such, rather offer a configuration field in the compilation process (similar to how settings are provided for the optimiser):
Where any function name listed here would take precedence in order they are listed and anything not listed would be freely sorted after them.
Also note that currently it is sorted by the selector (hash of the function name).
Last note, #4034 could obsolete this.
We are currently not using the optimiser, but I do agree that it might be better to put it there.
Also the binary search will affect all calls made. But for most contracts not all methods are called with the same frequency. If you as a developer know what methods are called the most you should be able to optimise for it. I think #4034 doesn't solve this ;)
I think this has a very bad complexity / usefulness ratio to be included as a feature for the code generator. I do not understand why you care about 400 gas but do not use the optimizer.
How many functions do you have? Why do you think binary search would not reduce the gas costs?
It was more that this seemed like an easy way to save gas. I do agree that if the complexity is too high this makes no sense. (Adjusting it by hand was quite easy ;) )
To the point why we don't use an optimizer: at some point we wanted to minimize potential sources of error. So by not using the optimizer we say the chances that the generated code contains an error is lower.
My comment concerning binary search was that a contract where the method ids have been sorted by usage could be more gas efficient than a contract that uses binary search (depends on the usage). But binary search will be definitely be an improvement compared to a current (unoptimized) solution.
#4034 is implemented now (albeit not merged for 0.5.0).
I think @rmeissner you should have a test when that's done, see the cost change and take the discussion from there.
I am still kind of leaning towards that adding an optimiser feature as described here is useful. It is better to offer such a safe solution, than leave contract developers do homebrew solutions.