2-layer Dispatch Table

[tjade273]

Abstract

Function dispatch should prioritize non-pure functions due to higher on-chain usage.

Motivation

Prompted by this stackexchange question

Most contracts in practice have a high ratio of view/pure to non-pure functions. It is generally seen as "free" to add, e.g. a getter for a public variable (deployment cost aside).

This has the unfortunate side effect of increasing dispatch costs for non-pure functions that are more gas sensitive. One solution is to add explicit dispatch priority syntax or optimizer flags ala #4858

Another reasonable solution is to have a 2-stage dispatch routine, where all state-modifying functions are dispatched before read-only methods.

Specification

In order to maintain compatibility with binary-search dispatch, each binary search JUMPDEST is prefixed by a jump to the secondary dispatch table. Lookups that fail (reach the end of their block binary-search block) will then try again in the secondary table.

Backwards Compatibility

This should not cause any backwards incompatibility, but will increase the size of generated bytecode by at least 1 OPCODE per binary search branch.

[chriseth]

One could argue exactly the opposite: view/pure functions are not only called from outside, they may also be called from other contracts. Especially if view/pure functions are part of the deployed bytecode, one could expect that they are only called on-chain - why would they be part of the bytecode otherwise? In that case, such cheap functions should stay cheap. On the other hand, if a function is expensive already, you do not save much by improving the dispatch routine for those functions.

[chriseth]

Continuing on that argument "if code is only called off-chain, it should not be on-chain" - I think clients should provide a way to call (not transact) contracts in a delegatecall-way, where you specify a different bytecode to be executed instead of the one that is on-chain.

[tjade273]

I agree in principle that only code designed to be used on-chain should be used on-chain, but that doesn't seem to happen in practice. It would be interesting to see some sort of separate off-chain code; you could do this by having a function that delegatecalls to any address provided by the 0x0 address (which can only be the sender in a simulated call).

Now that you mention it, in general this 2-level idea could be terrible for e.g. balance getters. There does seem to be demand lately for more flexible dispatch, but OTOH dispatch is a minor cost overall, so optimization is not going to pay off much.

[github-actions]

Hi everyone! This issue has been closed due to inactivity.
If you think this issue is still relevant in the latest Solidity version and you have something to contribute, feel free to reopen.
However, unless the issue is a concrete proposal that can be implemented, we recommend starting a language discussion on the forum instead.