Dmitry Murzin

After #5048 merged, executor related things (linker initialization, module instantiation, memory free) started to take noticeable amount of flamegraph. Potentially we could get good tps improvement with persistent executor, but...

Based on my testing, size of a transaction with a single transfer asset instruction is ~1.8KB (`CommittedTransaction` struct). So for 1 million transactions iroha will consume ~1.8GB, for 3 million...

Analysis of `CommittedTransaction` struct memory layout. Key results: * Minimal possible size of a transaction is 1436 bytes * Typical size of a transaction with a single transfer asset instruction...

Actually, we still have capacity=1 since we clone transactions in `Sumeragi::try_create_block` (this is a single peer case, not sure about multiple peers). Anyway would be nice to replace it with...

With #5096 and #5103 merged, memory usage expected to be the following: * fixed ~200MB for last 128 blocks stored in kura in memory * unbounded ~260 bytes per transaction...

`u64` is used for timestamps after #4841: https://github.com/hyperledger/iroha/blob/a27bc2eaa7e3cfab6c35cae3b2bcace63a3fee2b/data_model/src/events/time.rs#L100-L105 @mversic should this issue be closed?

Implemented in #5176

I tried to reproduce it locally and apart from degradation of tps over time, noticed that tps is very unstable. With single peer and configuration [as in this report](https://soramitsu.atlassian.net/wiki/spaces/QA/pages/4647780354/03.07.2024), and...

@Erigara yes, but the thing is, that currently each transaction is pushed two times to the queue. E.g. consider queue capacity is 8 and max transaction in block = 2:...

> And you want to be able to push transactions back at the beginning of the queue so that they are removed from the queue earlier? Yes, I think this...