Slow creating new instance of OkHttpClient()

[tprochazka]

Creating a new instance of OkHttpClient is very slow because initializing HTTPS support probably. It spends more than 500ms in CipherSuite class. I understand that it is probably important, but why it happens directly when a new instance is created and not during first HTTP request which happens every time on a background thread. It is very unusual, to do such time complex operation directly after the instance is created.

[yschimke]

Can you show a stacktrace of this? I believe you, but good to discuss with a specific code path.

Ultimately the cost of JVM SSL init + OkHttp init is either on creating first client, or first request. Both have drawbacks, e.g. in some cases apps can be doing startup with a loading screen, but then first request is faster which may be better for users.

[tprochazka]

Here is trace file https://www.dropbox.com/s/50eupuup8bplks8/okhttp.zip?dl=1

[yschimke]

https://aflame.rhye.org/trace/8D0D69D9EB476C425549B8B815477FA8

[yschimke]

I think there is an easy win here. Use a HashMap, change the static fields from a normal lookup to an (assumed to be unique) insert. Then on lookup, check the happy path first, and on failure, do a secondary lookup s/TLS_/SSL_/ or s/SSL_/TLS_/.

@swankjesse thoughts?

[yschimke]

On a desktop mac, roughly representation numbers

Before: Init Took 2.373407ms
After: Init Took 0.453405ms

[yschimke]

@tprochazka What device did you profile on?

[yschimke]

This is still a tiny amount of time relative to the first actual use of the native TLS library, which is roughly 100x more expensive and happens on first request.

[tprochazka]

The Trace is from Samsung S8+

[swankjesse]

@yschimke thumbs up on making things faster!