Reuse wasmtime instances, the PR

[pepyakin]

Fixes #5141

So far, we have bug #5036. TL;DR: Basically, the linear memory is not completely zeroed. It is zeroed enough for avoiding the issues #3011 was set to fix, but still not completely.

What it means is that the contents of the memory are preserved from the previous call. I don't yet fully know if there any ramifications of this approach. There are some thoughts on this in this comment, again TL;DR I am thinking if this is OK or not.

So this PR fixes #5141 as if #5036 was not a bug.

I am not absolutely sure if I understand all ramifications treating #5036 as not a bug though and if we want to go the way I outlined in the comment. So this PR gives us a point for doing the change, because AFAICT, it yields more performance than the current implementation.

In any case, this is still a useful PR that improves the status quo.

[parity-benchapp]

Finished benchmark for branch: ser-reuse-instances

Benchmark: Import Benchmark via wasm (random transfers)

Master: 728.80 ms
Branch: 722.09 ms
Change: -0.92%

[NikVolf]

/bench import

[parity-benchapp]

Finished benchmark for branch: ser-reuse-instances

Benchmark: Import Benchmark (random transfers)

Master: 696.77 ms
Branch: 694.00 ms
Change: -0.40%

[bkchr]

@NikVolf this should show improvements for syncing and not really for importing single blocks.

[arkpar]

Do these benches even use wasmtime? And if so, do they account for compilation overhead?

[NikVolf]

Do these benches even use wasmtime? And if so, do they account for compilation overhead?

they do, there is an issue with rocksdb cache for benchmarks currently though

[NikVolf]

@NikVolf this should show improvements for syncing and not really for importing single blocks.

@pepyakin said they should show improvement, so we decided to run them

[NikVolf]

And if so, do they account for compilation overhead

they do account for compilation overhead