Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve estimate_module_size calculation and doc comment #1666

Closed
webmaster128 opened this issue Apr 19, 2023 · 3 comments · Fixed by #1791
Closed

Improve estimate_module_size calculation and doc comment #1666

webmaster128 opened this issue Apr 19, 2023 · 3 comments · Fixed by #1791
Assignees
Labels
wasmer3/4 Changes related to the upgrade to Wasmer 3 and 4
Milestone

Comments

@webmaster128
Copy link
Member

We need some updated estimations on how much memory a module uses in the in-memory cache.

@webmaster128 webmaster128 added this to the 1.3.0 milestone Apr 19, 2023
@webmaster128
Copy link
Member Author

This percentage (~100.06%) was derived by comparing the serialised size to the size of the memory reported by massif. As such, is not considering mmaped memory, used in the module's storage.
Better to remove this comment, or update it to account for the size discrepancy due to mmaped storage.
We can also introduce a factor to multiply this module size, to get a better estimation using the old method.

@maurolacy do you know if additional mmaped memory is used here at all? I know modules are archived to disk using kryv so I would expect that the on-disk size is aktually a very good estimation of the in-memomory size.

@webmaster128
Copy link
Member Author

Okay I found #959 (comment) again, which explains things.

What we can do is create a patched CosmWasm 1.2 which exports loupe size and module size to determine a reasonable factor for real-world data.

@maurolacy
Copy link
Contributor

Okay I found #959 (comment) again, which explains things.

What we can do is create a patched CosmWasm 1.2 which exports loupe size and module size to determine a reasonable factor for real-world data.

That's a good idea. Based on the comment's data above, an initial (rough) factor is ~1.5.

Another option is to leave this aside, and just use the artefact size (disregard the store size, that is) as a proxy for the entire thing's size. Mentioning this for completeness. It has the benefit that is simple, it works, and it's what we already have.

@webmaster128 webmaster128 added the wasmer3/4 Changes related to the upgrade to Wasmer 3 and 4 label Jun 19, 2023
@webmaster128 webmaster128 self-assigned this Jul 24, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
wasmer3/4 Changes related to the upgrade to Wasmer 3 and 4
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants