Looks like Promise overhead is on the order of 25 ms for V8 nowadays: https://v8.dev/blog/fast-async -- so... not much?
-
-
Replying to @adambroach @fugueish and
"The above chart [which shows the 25ms you seem to be quoting] shows the doxbee benchmark, which measures performance of promise-heavy code." That's not just one Promise resolution.
1 reply 0 retweets 0 likes -
Sure, and if you're only invoking a single promise, execution time is negligible. I presumed we were discussing real-world impacts, not angels-dancing-on-a-pinhead tweaks.
1 reply 0 retweets 0 likes -
Replying to @adambroach @fugueish and
Your phrasing made
@fugueish come to the conclusion that "Promises aren’t even 60 FPS", which, reading you again more carefully, is I think the opposite of the conclusion that you wanted.0 replies 0 retweets 0 likes -
For what it’s worth, I think async crypto is not the right choice in JS, for the same reason why it’s not the right choice in any other language.
1 reply 0 retweets 6 likes -
I guess a good rule of thumb is “if it blocks your CPU core, it’s not async”? That principle would make I/O and WebGL async but crypto (AES-NI) sync.
1 reply 0 retweets 5 likes -
Blocking the CPU core doesn't mean it needs to block rendering, but when we give main-thread JS sync APIs, that's what folks do. I guess another point in the design space would be to make crypto worker-only?
2 replies 0 retweets 1 like
OMT layout sure would be nice (if it’s web compatible) ;) Anyway, how slow are we talking about anyway? AES-NI is really fast.
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.