I/O+bound isn't different to CPU-bound when responsiveness is at risk. Environments without threading rely on tasks deferring for responsiveness.
-
-
Replying to @slightlylate @jaffathecake and
Which is why I mentioned symmetric vs asymmetric operations. Computing a hash is not a responsiveness risk. We're talking operations where we look at avoiding malloc because it's on the radar at this scale.
1 reply 0 retweets 3 likes -
Replying to @davidben__ @slightlylate and
… the TAG should probably give some guidance about when a CPU-bound operation takes long enough to make it promise-based. e.g. Hashes and AES handle 1MB in about 1ms, which is probably fine to block the main thread, but we also just added img.decode() because images take longer.
3 replies 0 retweets 2 likes -
Replying to @jyasskin @davidben__ and
Also 1ms is somewhere between 2% and 10% of your main thread budget in a lot of situations... Getting non UI work off the main thread is critical to fixing a lot of mess in apps (native and web).
1 reply 0 retweets 3 likes -
Developers already can iterate over a giant array and do slow stuff. Nothing will avoid the need to think about jank. All we can do is forbid the really bad things while still making the things you need possible.
1 reply 0 retweets 0 likes -
Replying to @davidben__ @ElliottZ and
For network requests, this is clear. An RTT is an RTT. Crypto scales with data, and you often need to make lots of small calls. Look at the key schedule of any protocol. Adding async points between each 32-byte hash op costs perf and complexity.
1 reply 0 retweets 2 likes -
Replying to @davidben__ @ElliottZ and
If *really* worried about confused devs, sync + must be in web worker is a plausible start. Then you run your entire protocol on the thread. The important thing is to get the promises out of all the little intermediate steps.
1 reply 0 retweets 1 like -
Replying to @davidben__ @ElliottZ and
I'd like to see numbers. Promises were explicitly designed to allow for "fast forwarding" so that you don't need a full turn around the event loop. Might not be enough, but data matters.
1 reply 0 retweets 0 likes -
Replying to @slightlylate @ElliottZ and
(Am tied up packing for a big move but it sounded like others had numbers.) "Fast" depends on context. Overhead for an IO-bound event loop iteration is different from overhead for a small chunk of compute in it. We wouldn't push array lookups or object allocations into a promise.
2 replies 0 retweets 1 like -
Replying to @davidben__ @slightlylate and
I'd love to see data though. It's possible the APIs need a batch interface so you can hash multiple strings in one call if the per call overhead vs. computation cost is too high. Sync is not the only way to fix this.
1 reply 0 retweets 2 likes
I'm reminded of the original WASM module compilation API mistake.
-
-
Replying to @slightlylate @davidben__ and
Yeah... The OffscreenCanvas blocks forever commit() concerns me the same way. Some WASM devs want to make while(true) style apps, but that doesn't fit with the web. I don't know if "rebuild all APIs with SharedArrayBuffers yourself" is better than an event loop in your game.
0 replies 0 retweets 2 likesThanks. Twitter will use this to make your timeline better. UndoUndo
-
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.
& Web Standards TL; Blink API OWNER
Named PWAs w/
DMs open. Tweets my own; press@google.com for official comms.