Wasmer is slower for same length but bigger methods number

[Longarithm]

For same contract lengths, but different number of contracts, gas spent on empty function calls differs significantly. In the both cases below contracts' size is 1.7 MB:

| `aurora_engine` | state_migration (trivial) | 13 Tgas | | `make_many_methods_contract(70000)` from [https://github.com//pull/4529](https://github.com//pull/4529) | hello0 | 302 Tgas |

This is a serious issue because we currently estimate fees for function calls as base_cost + bytes_cost * contract.len() where coefficients are estimated by LSM. We compute them on a sample of contracts containing trivial methods using make_many_methods_contract from PR #4529 mentioned above. It gives us fees for the worst case we know so far, but still it overestimates load on real contracts by ~10x.

We would like to understand the cause of slowdown on Wasmer' side, because it currently blocks us from updating function call fees.

Double-check: after computing LSM, coefficients are base_cost = 48_080_046_101, bytes_cost = 207_939_579, and 48_080_046_101 + 207_939_579 * 1.7 * 10^6 ~= 353 Tgas >= 302 Tgas.

cc @bowenwang1996 @olonho @matklad

[matklad]

Looked into this today, hoping to find some easy wins, but, sadly, there seems to be none.

First, the serialized representation of both contracts actually differs -- although wasm len is the same, we store 3x more bytes in the cache for make_many_methods_contract.

Then, I looked at the profiles, and I didn't notice anything order-of-magnitude big. There were some unnecessary clones which yielded 30% perf increase for make_many_methods_contract, but, other than than, the stuff was just uniformly slower. It seems that the reason for that is that wasmer creates a bunch of runtime structs for every function, so it is a death by a thousands cuts.

After that, I've re-run the benchmark under wasmer1. It is faster, but there's still 20x gaps between the two contracts.

[Longarithm]

The first and very rough LSM run for two parameters - code length and number of functions - show the following coefficients:

Intercept = base_cost ~= 10 Ggas
code_byte_cost ~= 311 Mgas per KB
function_cost ~= 2 Ggas

The accuracy looks promising. If I multiply all coefficients by 2, I get strict upper estimation for my simple dataset.
According to #4814 (comment) such model gives ~= 4 Tgas fee for Aurora contract.

I will post more details later, also need to check how it behaves for real examples, especially ones in the topic.

[stale]

This issue has been automatically marked as stale because it has not had recent activity in the last 2 months.
It will be closed in 7 days if no further activity occurs.
Thank you for your contributions.

[stale]

This issue has been automatically marked as stale because it has not had recent activity in the last 2 months.
It will be closed in 7 days if no further activity occurs.
Thank you for your contributions.