fs::readdir performance in wasi is not great about wasmer HOT 7 OPEN

Well, as I mentioned elsewhere - when we tried to use wasix in the past, we got a hard-crash when one of the maintainers left their laptop running and it went to sleep mode. I totally get that bugs (even unexpected bugs) happen and are an inherent part of development, but we are very concerned about the added issue-surface this would add to our app.

This is to say that: if the separation is hermetic enough that we can trust it - we'd be happy to consider the upgrade. It would also have to exclude the relevant dependencies - not just at compile time, but also as part of the crates in order not to make extra work for our packagers.

Wasmer has served us very well over the years and we'd be happy to be able to keep using it. It's very much a shame for us that we are stuck on an older version.

from wasmer.

RUN-103 fs::readdir performance in wasi is not great

from wasmer.

Hey @imsnif , we are in the process of planning a refactor of the filesystem atm, which should improve greatly the speed for this case (and many others)

from wasmer.

Thanks @syrusakbary ! Will I be able to upgrade without adopting wasix?

from wasmer.

Hey @imsnif,

Will I be able to upgrade without adopting wasix

WASIX is a superset of WASI. One of the things that we can do is to expose only the wasi layer, so even if you use the wasix crate, you don't opt-in into the WASIX specific features (so basically, only WASI programs will be able to be run). Would that work for you @imsnif ?

from wasmer.

@imsnif while the new implementation is still in the planning stages, it will be much more layered and will allow fine-grained opt-in to certain parts, so limiting your compilation to WASI without the WASIX parts will be possible.

from wasmer.

@imsnif while the new implementation is still in the planning stages, it will be much more layered and will allow fine-grained opt-in to certain parts, so limiting your compilation to WASI without the WASIX parts will be possible.

That's great to hear! Just to be clear though so there aren't any misunderstandings: this is not just about compilation but also dependencies. We would not want to adopt a crate with lots of dependencies we're not using (eg. auxiliary dependencies for the networking stack or whatnot).

from wasmer.