Performance Estimates?

[rektide]

Hello. Over in whatwg/fs#7 there's a lot of pressure to make our new, upcoming, finally-lets-do-it-right file system api sync, because everyone wants their sqlite to run fast in a browser (a previous issue in the thread). Fair enough!

I apologize for the nosy ask, and I'm not really sure if this work can directly help speed up or replace asyncify or not. But might it? Are there any benchmarks on what improvements we've seen elsewhere? I'm not sure if we even base a baseline stack-switching v8 to test or not. Sorry again. But I'm hoping we can maybe get a little bit better an informed decision on how to shape the web's upcoming file api, and this work here seems like one of the most pertinent & relevant factors that could tip things one way or another. Thank you.

[fgmccabe]

Not completely sure how to respond. However the js promise integration effort is proceeding well.
Since it is a standards track effort it is never going to be lightning quick to ship.
As for performance we are definitely seeing encouraging signs compared to conventional asyncify

[dschuff]

For a slightly different perspective:
Maybe it's helpful to distinguish the cost of using emscripten's asyncify feature separately from the cost of using async APIs for filesystem calls?
The "general" performance cost of asyncify comes in 2 different components[*]. One is a "diffuse" cost: Every function that might be on the stack at the time of an async call has extra instructions at entry and callsites, so it becomes slower even when no async calls happen. The second is the cost of suspending and resuming at async callsites. My understanding is that js-promise-integration significantly improves both of these, and it's what @fgmccabe means by "encouraging signs". I don't have a good sense for the relative improvement between these 2 components, or how they've tested this.

The other cost is sync vs async API calls, e.g. speed/latency of a read call, independent of the suspend/resume cost. For example, if a read call that could return its result in just a millisecond or 2 has to wait for a turn of the event loop (plus other events that may fire?), is that a significant cost? Does the event loop run as soon as the result is available or does it have to wait for e.g. the next frame?

IIUC the cost to the user (i.e. difference in latency between a sync and async call) will be the sum of these (suspension plus event loop plus resumption).

Apologies if this is all obvious to you and you've already considered this carefully; I haven't been following the discussion closely. But it made me curious about it because it could be the case that if the cost from async alone is high enough, then it doesn't matter how fast suspension and resumption are.

It also brings up a question for @fgmccabe: the cost of a suspend and resume in asyncify is linear in the depth of the stack at the time of the call. Hopefully that's not the case for JSPI?

*actually there's also a 3rd component which is binary size. That cost is high enough to be a showstopper for many applications, but JSPI also mitigates it.

[fgmccabe]

Actually, the cost of suspend & resume in JSPI is constant. To be more precise, it is linear in the length of JSPI chain (the chain of modules a given Promise has to be propagated through before it gets to the browser's event loop). Normally, the length of this chain is 1.