-
Notifications
You must be signed in to change notification settings - Fork 801
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
Allow decomposition and composition of Modules without serialization #1933
Comments
The artifact is something very internal to the engine, and it might be refactored in the future. So the less we depend on it externally, the better! What do you think about having a method in the |
Fair point
That should solve most of the issue indeed. I'd keep unused |
Another approach could be to make |
This comment has been minimized.
This comment has been minimized.
I hided my previous comment and extracted the cash issue into #1943. This is the API change needed to build an in-memory artifacts cache: master...webmaster128:module-from-artifact |
I'm wondering what is slow in the first case of the file system cache. Is it the serialization/deserizalition, or is it the FS writing/reading operation? Would it solve your issue if you have an in-memory FS (I'm thinking of SQLite in-memory DB for instance)? |
We already have two layers: FS cache and in-memory cache. This request is for the in-memory cache only. Here the slow part is serialization/deserialization. Using Wasmer 0.17, we could cache modules in memory without serialization which has been created after identifying that module deserialization is costy. This loads cached modules in microseconds. With Wasmer 1.0, the new API forces us to serialize modules in order to swap out the store, which creates a 30x slowdown from 50µs to ~1500µs. |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
@webmaster128 it would be nice to see a new benchmark of loading times. (Note, we allow chains to pin all popular contracts in memory and if we can get these near native speed, it allows using wasm contracts for more core functionality) |
We solved the problem differently for Wasmer v1 and v2. The modules remain in memory along with their In Wasmer 3, the modules do not carry a store anymore, so the situation will change in some way. So I think it is best to close this issue and see how things evolve with version 3. |
Motivation
In CosmWasm we created a file system cache and an in-memory cache for recently used modules. This gives us module loading times of 1-2ms for the file system cache and 43µs for the memory cache, which is great.
The two caches work a bit different right now. The file system cache uses
Module::serialize_to_file
/::deserialize_from_file
, which basically delegates those operations toArtifact
. The in-memory cache stores theModule
s directly.Now the problem is that for symmetry and due to metering, I want to use a new
Store
every time I take aModule
from cache. And what I really want to cache isArtifact
in both cache types. My current workaround involves serialization, which is a slow hack to get the artifact from the Module. However, it would be nice to be able to decompose a Module inArtifact
+Storage
and compose aModule
fromArtifact
+Storage
without serialization.Proposed solution
Module::artifact
stable and publicModule::from_artifact
publicArtifact::sizeof
, which retruns the size of the artifact in memoryAlternatives
Don't know, maybe you have some thoughts?
Additional context
–
The text was updated successfully, but these errors were encountered: