Question (Documentation)

[boardperson]

I'm sure this isn't the right place to ask this but it may be of help for future visitors;

The readme mentions quicker-than-native speeds, yet I'm hard-pressed to find any resources that explain why WASM would outperform native. Could anyone point me to an explanation? I'd be happy to create a PR updating the readme to include this if so desired

Thanks!

[cchudant]

It is written in the medium post i think.
Basically, in io intensive operations / code that calls syscalls a lot, a lot of time is wasted in context switching (processor goes from userland, to kernel space - ring 0)
The reason we need context switching in syscalls is to sandbox user code so that it cannot do everything the kernel can.
In webassembly, security is achieved differently; each module is sandboxed and can only access its own memories, and modules communicate with each other through simple function calls.
This means that when we use webassembly, provided our runtime is spec-compliant and doesn't contain any bug that could allow webassembly code to do anything it is not allowed to, and ignoring meltdown and spectre attacks, we actually don't need the hardware-based sandboxing.
This means that basically, by running webassembly in the kernel, "syscalls" (or host calls) are just simple function call with no context switching, and their overhead is very minimal. That is how you can achieve faster-than-native speeds with webassembly in the kernel.