State cache and other performance optimizations

[arkpar]

Closes #257

Major change introduced in this PR is canonical state cache. This works in the same way as in parity-ethereum. The cache caches a single state C that is considered "canonical" or "best". Any state S that is derived from C can use cashed value cache as long as the key is not overwritten in any of the blocks between C and S.

A few other minor changes:

• changes inCallResult and storage root calculation are not really required for each call. So the whole struct is dropped.
• Executor now queries the code hash from storage/cache instead of querying the code and hashing it every call.
• wasmi module instance is reused for each call. The instance is now cached per thread.

[gnunicorn]

Fine overall, a few TODOs, wraps and smaller style remarks.

[pepyakin]

Assuming that used_size returns the highest written address so far, this will be set to the address of last written byte (shouldn't it be +1?) and then in Heap we assume that we can allocate memory starting from this address.

This completely ignores the fact that compiler might reserve some space without actually writing to it (aka BSS).

I think this would work for now since rust doesn't use start function at all atm and we only have rust runtimes now. But I'm not sure that this is universal approach, since the behavior of rust can be changed and/or somebody will want to use a language other than rust.

Of course, we can impose constraints on wasm modules to be compatible with substrate, however, I think this might be not the best decision and could backfire even with Rust.

UPD: withdrawn concern about the start function run.

[arkpar]

Assuming that used_size returns the highest written address so far, this will be set to the address of last written byte (shouldn't it be +1?) and then in Heap we assume that we can allocate memory starting from this address.

+1 is not required. The buffer should be schrinked to exactly this size.

This completely ignores the fact that compiler might reserve some space without actually writing to it (aka BSS).

Not exactly. This relies on wasmi to always initialize all data segments, as it does now. Since this code already relies on some of the wasmi internals I don't think this is much of a stretch.

The bottom line is simple. If the interpreter can do 200bps as demonstrated here it should provide a convenient interface to be used efficiently. I'm sure compatibility can be achieved without sacrificing performance.

[gavofyork]

re: the +1 remark, wasmi documentation doesn't appear to be consistent:

   /// Returns current used memory size in bytes.
    /// This is the highest memory address that had been written to.
    pub fn used_size(&self) -> Bytes {
        Bytes(self.buffer.borrow().len())
    }

i would presume that the buffer.len() actually does give a size, rather than an index (i.e. you write to index 0 implies your buffer is size 1).

so the remark "This is the highest memory address that had been written to" is wrong: it should read "This is one more than the highest memory address that had been written to".

@pepyakin could you confirm?

[arkpar]

That function was added by me and the documentation is indeed incorrect.