O_DIRECT and other performance considerations

[DemiMarie]

Right now, it appears that this proposal does not support in-place overwrites. Furthermore, all access is buffered, and buffers are owned by ECMAScript code, rather than by the user agent.

Unfortunately, this is not the best way to get top performance. I will use Linux’s io_uring as it is the only high performance API I am remotely familiar with, but the general pattern should be similar for other such APIs as it is largely dictated by hardware. To get high performance, one needs:

• Direct I/O (bypassing the page cache).
• Asynchronous I/O (already present in the current proposal).
• Support for in-place and append writes.
• The ability to submit requests in parallel from multiple CPU cores.

For maximum performance, pre-registered buffers are required.

If this is not planned, it would be useful to say that such applications are out of scope.

[DemiMarie]

It is worth noting that a web app will always be slower than a highly-optimized native app for highly storage-intensive workloads. The reason is that many such workloads just assume they have the entire machine to themselves. This allows all sorts of optimizations, such as busy-polling to eliminate interrupt overhead and using almost all of the machine’s memory for a massive userspace buffer pool. ScyllaDB even bypasses the kernel’s network stack, using DPDK (via SeaStar) to drive the network hardware directly! I would not at all be surprised if there is a bunch of hand-written assembler too.

For the web platform, I think the main advantage of efficient APIs is not to improve performance in benchmarks, but rather to improve responsiveness and use less power. What that means in practice is not something I am certain of at all, but I strongly believe that is the direction to go in.