-
Notifications
You must be signed in to change notification settings - Fork 101
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
feat(sandbox): Implement LRU cache for Wasmer modules #3801
Conversation
Consider bump host functions versions that use this, just in case? @grishasobol ? |
This actually acts as a drop-in host replacement. Additionally, the current implementation does not affect the file cache in any way, since the file cache is empty every time the node is started. but I left the interaction if during further tests I have to clear the cache in memory |
Ok, we can consider, but actually I cannot see reasons to do this. Everything must work fine even for old blocks |
Okk, maybe test resyncing from scratch then @ukint-vs |
Testnet from start is ok. Without any problems |
I'd consider using mapping within LRU caching to avoid 1024 slices comparison, e.g. use 64 bytes from the middle as keys. Mostly, not a big deal cause wasms are differ in size and comparison goes super fast |
We can't guarantee that the bytes will be unique. Yeah it's not a big deal and it's better to avoid vec manipulation which can lead to unnecessary logic. I think we can pass code_id in the future. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good, just some comments to consider
In-memory cache reduces wasmer module access latency by up to 50%.
It also has a small memory footprint (I will do more testing on the testnet) that can be moved to the swap if something goes wrong.
We don't need to rely on the filesystem, now a new temporary directory is created every time, so there is no point in serializing modules to the filesystem, temp сache lifetime is the same as that of the node.
I would remove file caching if in-memory approach doesn't cause any problems.
module <- LRU <- file cache <- compile
benches:
@gear-tech/dev