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.
-
-
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 @slightlylate and
(Not sure yet how much I believe this claim) Perhaps CPU-bound alone justifies sync, but maybe not callable on UI thread. You won't do better than a background thread, be it app- or browser-owned. Former is more flexible and inherits existing DoS limits. Latter needs custom limit
1 reply 0 retweets 1 like -
Replying to @davidben__ @jyasskin and
"UI thread" is the sort of assumption in system design that frequently defeats responsiveness (while improving throughput). Most engineers live in someone else's framework; also responsiveness is king on the client side.
0 replies 0 retweets 2 likes -
Replying to @BRIAN_____ @davidben__ and
I hear compilers are "a thing" these days.
2 replies 0 retweets 4 likes -
Replying to @slightlylate @BRIAN_____ and
If equivalent WASM'd crypto methods are outperforming native ones, can we at least agree that's a problem worth solving?
1 reply 0 retweets 3 likes -
Replying to @jaffathecake @BRIAN_____ and
"outperforming" is multi-faceted
1 reply 0 retweets 3 likes -
Replying to @slightlylate @BRIAN_____ and
For this particular crypto case it'd be good to know specifics. What's the size and shape of the issue before and after WASM.
1 reply 0 retweets 1 like -
Replying to @jaffathecake @BRIAN_____ and
WASM doesn't change anything other than that people who were C/C++ folks were sold a "minimal changes" bill of goods.
1 reply 0 retweets 2 likes
WASM is a capability in the sense that getting half your CPU back is a capability. In a tight loop, that's transformative. It changes nothing about the ecosystem outside that tight loop.
-
-
Replying to @slightlylate @BRIAN_____ and
Right, so it's worth learning more about cases where that becomes better than native implementations
1 reply 0 retweets 2 likes -
Replying to @jaffathecake @BRIAN_____ and
Native vs. non-native isn't meaningful. It's about scheduling; who makes sure that the "ui thread" (a convention loosely enforced) remains responsive? What measures are taken to enforce it? At what cost?
1 reply 0 retweets 2 likes - 2 more replies
New conversation -
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.