… 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.
-
-
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 1 like -
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.
2 replies 0 retweets 2 likes -
Replying to @ElliottZ @davidben__ and
Every app and every intermediate (not lower layer) crypto library would need to be rewritten, if there is no sync interface, because they have *all* been written to use a sync interface. Imagine porting BoringSSL or a BoringSSL-based app to WebAssembly. All of BoringSSL is sync.
3 replies 0 retweets 1 like -
Replying to @BRIAN_____ @davidben__ and
I suppose I could be convinced having a sync crypto interface in a worker makes sense, though it doesn't make sense to do any of that work on the same thread that does webgl or the UI main thread.
1 reply 0 retweets 2 likes
Right, just like you wouldn't allow WebAssembly to run on those threads.
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.