LD Init taking more time than its Timeout suggests

[efguydan]

Is this a support request? This issue tracker is maintained by LaunchDarkly SDK developers and is intended for feedback on the code in this library. If you're not sure whether the problem you are having is specifically related to this library, or to the LaunchDarkly service overall, it may be more appropriate to contact the LaunchDarkly support team; they can help to investigate the problem and will consult the SDK team if necessary. You can submit a support request by going here and clicking "submit a request", or by emailing support@launchdarkly.com.

Note that issues filed on this issue tracker are publicly accessible. Do not provide any private account information on your issues. If your problem is specific to your account, you should submit a support request as described above.

Describe the bug Hello. We are trying to update our LD Sdk from 3.6.0 to 5.3.0 but we have noticed a huge jump in the time it takes to initialize the SDK. Going above even the timeout we have indicated

Here is the code snippet of our init

private fun createConfig(): LDConfig {
        val mobileKey = "KEY_HERE"
        val secondaryMobileKeys: Map<String, String> = mutableMapOf(
            "secondKey" to "KEY_HERE",
        )
        return LDConfig.Builder()
            .mobileKey(mobileKey)
            .secondaryMobileKeys(secondaryMobileKeys)
            .evaluationReasons(true)
            .disableBackgroundUpdating(true)
            .build()
    }

fun initLaunchDarkly() {
        val time0 = System.currentTimeMillis()
        val future = LDClient.init(application, config, user.toLDContext(), 0)
        val time1 = System.currentTimeMillis()
        logE { "TimingTiming - ${time1 - time0}" }
}

The code above gives a time of 4813 ms

We were able to reproduce this down to version 4.0.0.

To reproduce Included the SDK in our project and ran the app. This happens on every install and the time does vary between 2 and 5 seconds

Expected behavior The set timeout should be respected

SDK version 5.3.0

Language version, developer tools Kotlin - 1.9.23

OS/platform Android 14

Additional Context This also happens when we use the deprecated init that returns a future. future.get() respects the set timeout but LDClient.Init which Is expected to take negligible time sometime takes over 5 seconds

[tanderson-ld]

Hi @efguydan, thank you for reporting this. Do you see this issue on a variety of devices and OS versions? It seems unlikely to be related so it could be good to eliminate those as possible root cause.

Has anything else in the application changed along with the SDK version and necessary code updates as part of version migration?

Does this slow initialization happen 100% of the time? If not, what percentage of the time do you see the slow behavior?

Have you changed anything related to LDUser/LDContext anonymity or made changes to the set of attributes you include in the LDUser/LDContext?

Thank you! We'll be looking into this in the next day or so.

[efguydan]

Hey @tanderson-ld. Thanks for the quick reply!

• We encountered this issue on Google Pixel 4a (5G) and Google Pixel 8 both on Android 14.
• Yes, as we migrated from 3.6 to 5.x, we had to change from the LDUser approach to a LDContext approach.
• The slow init happened pretty much all the time but the time varied. From 2 seconds to 6 seconds. Most of the time around 5 seconds
• on 3.6, we used to add .anonymous(true) to out LDUser objects, if the user was not logged in. We got rid of this parameter completely in 5.x.

I hope these help your investigation. Thanks!

[efguydan]

Hey @tanderson-ld , We tested the update with a minified (obfuscated) release build and the timing was as we normally expected.

Attached is an image with our tracer which measures the same time I was reproducing with the logs locally.

The test was carried out with the same device as before. Google Pixel 4a (5G).

Does this bit of information help? Thanks.

[tanderson-ld]

Hi again @efguydan. Could you clarify your last comment? You say "timing was normally as we expected" and then "the same time I was reproducing with the logs locally". I'm not sure if you're referring to the same behavior as you saw when using 3.6 or the same issue the ticket was opened for.

[efguydan]

Sure @tanderson-ld .

So the behaviour with debug builds was described in the original description of this issue. i.e. (2s to 5s) with version LD 5.3.0

However, testing with a release build that has been minified & obfuscated leads to a more regular time under the same conditions (device & network). i.e. (200 to 500 ms) also with LD version 5.3.0.

[tanderson-ld]

Interesting. I don't believe we have any logic in our SDK that varies based on debug vs release build. Do you vary any other analytics or tracing tools based on debug vs release?

[efguydan]

Hi @tanderson-ld , Thanks for the reply.

No, We don't vary analytics/tracing tools based on debug vs release. Regardless, the only thing we have changed here is the LD version (from 3.6 to 5.3) and the changes it requires - migrating from LDUser to LDContext

[tanderson-ld]

Hi again @efguydan. We haven't found any other theories at the moment. Is there any chance the behavior existed in debug builds when using 3.6 and is just being noticed now?

[efguydan]

Hey @tanderson-ld , Thanks for the reply. I tried again on version 3.6 and No, we didn't have the issue then. I tried on the subsequent version 4.0 and the issue was present so It's safe to say it was part of the changes that were shipped with this version.

[tanderson-ld]

@efguydan, have you ever seen the slow init time in an app build using the release configuration?

[efguydan]

Hey @tanderson-ld , sorry I missed this.

No we haven't really noticed slow init times of this nature in release builds. We only notice the occasional timeouts.