25

The optimizer seems like magic even to me. chriseth (He is the main DEV developer of solidity) would probably be in a better position to answer your question than myself. Here is an interesting high level overview though, which I hope answers your question. Everything below is from the solidity docs. Internals - the Optimizer The Solidity optimizer operates ...


12

The downside is that optimization adds extra complexity, and more complexity means more bugs. See this post for a previous bug in the optimizer: https://blog.ethereum.org/2017/05/03/solidity-optimizer-bug/ Solidity bugs can be rather terrifying: If the EVM is buggy we may be able to upgrade the network to fix it, but it's not clear that there's anything we ...


7

Here is more information about storing data in solidity https://solidity.readthedocs.io/en/latest/introduction-to-smart-contracts.html#storage-memory-and-the-stack Those variables, which you defined, will be stored in stack(if there is a space and you keep them in one function). in case if compile will optimize it properly it will be for free, if not, each ...


7

Given the high cost of blockchain-based computation, it is definitely worthwhile to performance optimise the computations performed in the chain itself. One basic technique used by almost all developers of blockchain-based applications is to develop applications in a testing environment where the gas cost of using the application can be repeatedly measured ...


7

Obviously it is really simple: The optimizer settings are in the wrong place. I used the example provided here but according to the documentation it needs to be under settings:{...} in the solc config. So this: compilers: { solc: { version: '^0.5.0', settings: { evmVersion: 'byzantium' // Default: "petersburg" }, ...


6

There are a few techniques which can be used depending on what you're optimizing for: Deploy libraries Enable compiler optimizations Network-specific tips & tricks Some contracts are pre-compiled, allowing for quick access in Solidity to otherwise complex functions such as ECRECOVER, RIPEMD160, SHA256.


4

It depends on the settings used when compiling the Solidity. https://solidity.readthedocs.io/en/v0.4.25/using-the-compiler.html As tested by @Aquila, compiling with the optimizer leads to the same bytecode and gas cost. If the optimizer is not used, the compiler would produce more bytecode, and the gas cost would be higher.


4

They're not mutually exclusive concepts. That code snippet originates here, to the best of my knowledge: https://blog.colony.io/writing-upgradeable-contracts-in-solidity-6743f0eecc88/ The gist of the idea is the separation of storage and logic. Logic contracts that could be replaced without loss of data or the need to migrate data. This approach is based ...


4

No, all the collection data types are very basic. This may be considered a design decision to keep the execution very cheap and will therefore not change in the future. To my knowledge, no library for binary search in data types yet have been published. The only similar thing I know is the iterable map implemented as a library: https://solidity.readthedocs....


4

In storage, variables are packed tightly, so your struct will fit in one word. See this page of the docs: http://solidity.readthedocs.io/en/latest/miscellaneous.html For parameters, packing's less important since it's ephemeral data. Function arguments are always in memory: https://solidity.readthedocs.io/en/latest/frequently-asked-questions.html#what-is-...


4

EIP-1884 changed the cost of an SLOAD from 200 to 800, which explains why you are seeing exactly 600 more than expected. It looks like the yellow paper has not been updated to reflect this change. Edit: I have opened a PR on the yellow paper repository to resolve this issue.


4

Yup, it does cache the numbers, even without the optimizer enabled! When passing 65535 (max uint16) as the parameter x, it costs 1003 gas to run either foo or bar. I ran this test with Solidity v0.8.3 on Remix. contract PowersOfTwo { uint256 internal constant TWO_POW_1 = 2**1; uint256 internal constant TWO_POW_2 = 2**2; uint256 internal constant ...


3

You could start by using a uint type for the loop variable rather than uint8. This is not obvious, but the compiler introduces extra code to do type-coercion when you use types smaller than 256-bits. This uses extra gas. The main overhead cost will be the array bounds checking for my_array[i] which the compiler inserts whether you like it or not. Currently ...


3

There's an implementation of binary search for sorted integer arrays, here. Note that this is look-up only, and you'll have to change the handled data type/structure from int to whatever your structure is.


2

In the time since this question was asked the following post has been made on the official Ethereum blog: Go Ethereum’s JIT-EVM This helps to answer: What optimizations does Geth's --jitvm do? When the native byte-code is run for the first time, we also compile a JIT program in the background. (The JIT version is then run on subsequent executions.) "...


2

Regardless of how a contract is executed, it's the EVM's accounting that matters. The protocol doesn't know if you're executing a contract on x86, a ARM7, a 6502, or pen and paper. What it does know is how much each step in the EVM costs, which is the same regardless. Solidity's optimization, by optimizing the EVM-level code, makes contracts cheaper in gas. ...


2

The same "light client" techniques that work for getting ether balances works fine for getting data from a smart contract's storage. See https://github.com/ethereum/wiki/wiki/Light-client-protocol for how this works in Ethereum. The first use case covers this: A light client wants to know the state of an account (nonce, balance, code or storage index) at ...


2

Does the unoptimized compiler, when compiling above code, call SSTORE twice or once? Yes, the unoptimised code will call SSTORE twice. However, the second SSTORE to the same storage slot will only cost 5.000 gas, since it is only resetting the value in an existing slot. (See "Is the cost of updating storage different than the cost of adding to storage?") ...


2

You can pack all bools in a row into a single uint and save on storage updates: pragma solidity 0.4.19; contract Test { mapping (uint => uint) public grid; function check(uint x, uint y, uint size) public { for(uint i = 0; i < size; i++) { uint row = grid[x + i]; for(uint j = 0; j < size; j++) { ...


2

A storage slot is 256 bits, as are hashes, ETH amounts etc, so it's simpler to standardize on returning a 256-bit number. However, if you need a timestamp in your contract you are under no obligation to store 256 bits: It's simple to cast it to a smaller size. This will often provide a gas saving if you're storing other small pieces of data at the same ...


2

When storing data into a Solidity mapping, there is no cost for storing the key. The key is not actually stored anywhere. The sha3 hash of the key is used as the storage address for the value. For example, uintStorage[0x123] = 989898; only executes one SSTORE instruction. This is also the reason why it's not possible to loop over all the values in a ...


2

Seconding Edmond's concerns about the loops. In my opinion, the need to enumerate the list is questionable. The contract could work on an append-only basis with a simple flag to indicate "sold" and events that chronical additions and removals. Clients would then be able to compute, for themselves, which cakes remain available for sale and the contract would ...


2

It totally depends on how the transfer function is implemented and what it does. I ran some tests with a bare-bones ERC20 contract. Or, actually it doesn't anymore implement all needed functions but it implements the relevant functionality. With the code given at the bottom of this post, Remix gives me a transaction cost for transfer at 51310 gas. Let's ...


2

The code in Ethereum is executed on the Ethereum Virtual Machine which is a stack-machine which executes instructions. A call to any contract starts with the instruction pointer at 0 meaning that the first instruction in the code placed on an address is always executed first. A short introduction to how function calls are handled in Ethereum, on an opcode ...


2

Edited Answer The reason people like using uint256 for most calculation is that OpenZeppelin has a SafeMath library for uint256 that prevent number overflow for sol version < 0.8. Additional casting will cost gas, so it's more efficient to keep number as uint256, and do math calculation all in uint256, instead of reading a shorter bit number and cast it ...


1

the answer lie in this article: https://link.medium.com/7oxDTDmKpZ tl;dr: they are the same but the order of method_id make func1 more expensive than func2 Update: So i have try to my theory it seem like somehow it is the solidity function name problem. The reverse code: pragma solidity ^0.5.0; contract Test { uint public value; function func2(uint ...


1

These loops, particularly in remove(), are a red flag: Your array can grow to an unbounded length, including if someone increases it maliciously, at which your contract will hit gas limits and become unusable. This is only OK if you can put explicit bounds on the length of the list - for example if someone tries to add an 11th unsold cake, revert the ...


1

This is not an efficient way to keep a trace of mapping values. Refer this article to understand how to maintain referential integrity in solidity. For the above code, the time complexity of function addValue is O(N) as if an argument b is false you end up iterating an array of addresses valuesTrue to search if there is an address already inserted whose ...


1

It could be a good solution, but each transaction has an inherent gas cost of 21,000. A good medium between your two solutions could be to do the work off chain, and have your contract take in the results in bulk (i.e., take in an array). It would cost less gas overall, and you can fiddle with it to figure out how many you can take at a time to avoid the ...


1

From a quick test on Remix, it looks like enabling optimization does not get rid of the MOD opcode in the following code, so I believe the answer is "No, you cannot trust solc to perform this optimization." contract Test { function test(uint256 x) public pure returns (uint256) { return x % 4; } }


Only top voted, non community-wiki answers of a minimum length are eligible