WasmFS slower than IDBFS on small reads and small writes

[galileolajara]

Hi,

I've read in the docs that WasmFS is a new filesystem that can be used to persist the virtual filesystem in emscripten. I also read in many articles online that WasmFS is about 2x faster than IDBFS.

However, I have an app that's doing small reads and small writes (less than 512 bytes) and I've noticed that WasmFS+OPFS is more than 2x slower on this scenario than IDBFS.

Is there some special config or compiler flag that I need to enable to make small reads and small writes on WasmFS+OPFS have similar performance to IDBFS?

Version of emscripten/emsdk:
emcc (Emscripten gcc/clang-like replacement + linker emulating GNU ld) 4.0.7 (8dc91db)
clang version 21.0.0git (https:/github.com/llvm/llvm-project 57025b42c43b2f14f7e58692bc19cd53d1b8a45e)
Target: wasm32-unknown-emscripten
Thread model: posix

[kripken]

Speed depends on the specific backend. It sounds like you are comparing OPFS (with WasmfS) to IndexedDB (with the old JS FS), so you may have found a performance issue with OPFS. That is surprising, but definitely possible. Which browser did you see this speed difference in, as the problem may be there?

@tlively is there some known speed issue with small reads and writes in OPFS? I vaguely recall some locking...

[tlively]

We're still doing the nutty thing where we fall back to the legacy blob API rather than OPFS APIs when a file is open only for reading. This allows reads from multiple tabs to happen at the same time. Doing #21869 should remove this performance cliff.

@galileolajara, in your tests, were you opening files only for reading or where you opening them for read/write?

[galileolajara]

Speed depends on the specific backend. It sounds like you are comparing OPFS (with WasmfS) to IndexedDB (with the old JS FS), so you may have found a performance issue with OPFS. That is surprising, but definitely possible. Which browser did you see this speed difference in, as the problem may be there?

@tlively is there some known speed issue with small reads and writes in OPFS? I vaguely recall some locking...

The browser I used that have performance issues is both Google Chrome and Microsoft Edge. I haven't tested it on Firefox yet because the app is showing blackscreen in Firefox if I build with WasmFS.

We're still doing the nutty thing where we fall back to the legacy blob API rather than OPFS APIs when a file is open only for reading. This allows reads from multiple tabs to happen at the same time. Doing #21869 should remove this performance cliff.

@galileolajara, in your tests, were you opening files only for reading or where you opening them for read/write?

I experience performance issues with small reads on files that are open with O_RDONLY | O_SHLOCK | O_NONBLOCK. I also experience performance issues with small writes on files that are open O_RDWR | O_EXLOCK | O_CREAT | O_TRUNC | O_NONBLOCK. I don't open files with read-write permissions.

[RReverser]

It sounds like you are comparing OPFS (with WasmfS) to IndexedDB (with the old JS FS), so you may have found a performance issue with OPFS. That is surprising, but definitely possible.

FWIW we ran into this (a pretty severe slowdown) as well in one of the projects where I tried to migrate to WasmFS.

As far as I could tell, it happens because IndexedDB on the old FS actually loads everything into MEMFS as its intermediate cache to deal with async nature of IDB (hence the whole syncfs API mechanism), whereas WasmFS + OPFS actually has to go and read from the filesystem each time. Of course, reading from memory is a lot faster regardless of a chunk size used.