I'm fairly certain this is WontFix/WorksAsIntended

I realize this may be controversial, but we do the cryptography on the IO thread, without any attempts to hop threads, because we know that the overheads for those thread switches quickly dominates and destroys performance (to the tune of multi-MS latency, on average). We did this on Linux and ChromeOS when we had to, for smart card.

We know that there are some types of crypto that can be slow on devices. Private key operations (such as client certs) are one example. Key negotiation with pathelogically large keys is another. Post-quantum crypto is another. Moving crypto itself to another thread is a non-starter for performance.

While moving networking out of process has been discussed (and is not staffed in a way that would address this problem anyways), I don't believe it's planned for Android.

Fundamentally, we're trying to do CPU work. The IO thread, since the beginning of //net, has been to do as much the CPU-bound work it can within a turn, and only yield for operations with external dependencies (e.g. blocking on network or file system IO). I realize that some teams may disagree with this philosophy, but like Chesterton's Fence, it may be important to understand why it exists in the first place, and the performance implications otherwise.

Just sharing this all to help manage performance expectations while we dig in, and see if there's any low-hanging fruit that can be optimized.

It should not be moved off-thread without much much more investigation. We've had it off-thread before on CrOS and Linux due to NSS limitations and it was a huge mess (and caused performance problems). We should find out where that 4ms is coming from and go from there.

What site were you connecting to?

(Private key operations are actually already off-thread but that's because, as Ryan mentioned, smartcards involve hardward access and blocking RPCs and whatnot.)

I was using android webview and doing a search with the google search app. So probably google.com? Here's a trace from chrome_public_apk, doing a google search. The DoHandshakeLoop events happen near around 5s in. I had to clear the cache first though, since additional searches didn't seem to trigger this.

From the trace, I don't think there's any blocking behavior. A few of them finished without being descheduled.

Deleted: trace_chrome_ssl.zip 649 KB

trace_chrome_ssl.zip 649 KB Download

Can you provide full details about your Chrome configuration? The "Did a trunk build" may be a sign that this is a local issue

(For context, we once lost a week of debugging BoringSSL+Chrome interactions, only to realize the developer reporting the perf traces was using a custom allocator in their build, and it was the allocator responsible for the perf issues)

I just got home. I'll try an archived release build tomorrow, which might be easier than trying to reporduce my local build.

Same thing with the archived release build from last night 56.0.2900.3. The ssl events happen around 5.7s

Deleted: trace_m56_ssl.zip 2.4 MB

trace_m56_ssl.zip 2.4 MB Download