GitLab is going to be shut down, which is unfortunate for all those who use it.
More information can be found here https://github.com/paritytech/ci_cd/issues/1041
@@ -166,7 +166,8 @@ This function performs the following steps:
In the course of the execution this function can perform up to 2 DB reads to `get_balance` of source and destination accounts. It can also induce up to 2 DB writes via `set_balance` if flushed to the storage.
Moreover, if the source balance goes below `existential_deposit` then the account will be deleted along with all its storage which requires time proportional to the number of storage entries of that account.
Moreover, if the source balance goes below `existential_deposit` then the transfer is denied and
returns with an error.
Assuming marshaled size of a balance value is of the constant size we can neglect its effect on the performance.
...
...
@@ -187,6 +188,23 @@ implementation they just involve a DB read.
For subsequent calls and instantiations during contract execution, the initialization requires no
expensive operations.
## Terminate
This function performs the following steps:
1. Check the calling contract is not already on the callstack by calling `is_live`.
2.`transfer` funds from caller to the beneficiary.
3. Flag the caller contract as deleted in the overlay.
`is_live` does not do any database access nor does it allocate memory. It walks up the call
stack and therefore executes in linear time depending on size of the call stack. Because
the call stack is of a fixed maximum size we consider this operation as constant time.
**complexity**: Database accesses as described in Transfer + Removal of the contract. Currently,
we are using child trie removal which is linear in the amount of stored keys. Upcoming changes
will make the account removal constant time.
## Call
This function receives input data for the contract execution. The execution consists of the following steps: