Lazy uuid generation for SentryId and SpanId

[lbloder]

📜 Description

Use LazyEvaluator to generate UUID on demand in

• SpanId
• SentryId

💡 Motivation and Context

Fixes #3325

💚 How did you test it?

📝 Checklist

• I reviewed the submitted code.
• I added tests to verify the changes.
• No new PII added or SDK only sends newly added PII if sendDefaultPII is enabled.
• I updated the docs if needed.
• Review from the native team if needed.
• No breaking change or entry added to the changelog.
• No breaking change for hybrid SDKs or communicated to hybrid SDKs.

🔮 Next steps

[github-actions]

	Messages
📖	Do not forget to update Sentry-docs with your feature once the pull request gets approved.

Generated by 🚫 dangerJS against 58a00c4

[Angelodaniel]

Hey @lbloder, I was wondering on how did you test this part? It's not included in the PR.

[adinauer]

@Angelodaniel do you expect problems somewhere? If so, what areas?

[github-actions]

Performance metrics 🚀

	Plain	With Sentry	Diff
Startup time	392.57 ms	447.13 ms	54.56 ms
Size	1.70 MiB	2.36 MiB	670.62 KiB

Previous results on branch: feat/lazy-span-id-v8

Startup times

Revision	Plain	With Sentry	Diff
081906a	544.44 ms	604.34 ms	59.90 ms
e2e56a0	417.82 ms	484.86 ms	67.04 ms
234085b	560.06 ms	587.22 ms	27.16 ms
2601edf	472.73 ms	518.83 ms	46.10 ms
ab1b958	427.50 ms	489.06 ms	61.56 ms
5132e04	431.47 ms	443.96 ms	12.49 ms

App size

Revision	Plain	With Sentry	Diff
081906a	1.70 MiB	2.35 MiB	665.19 KiB
e2e56a0	1.70 MiB	2.36 MiB	670.59 KiB
234085b	1.70 MiB	2.36 MiB	670.52 KiB
2601edf	1.70 MiB	2.35 MiB	669.02 KiB
ab1b958	1.70 MiB	2.36 MiB	670.54 KiB
5132e04	1.70 MiB	2.36 MiB	670.58 KiB

[kozaxinan]

This toString is called from multiple places. since uuid wont be changes. it is good to cache that. but also this toString will do unnecessary calculations.
Please consider holding toString value instead of uuid similar to SpanId or also cache the toString result.

[kozaxinan]

It is more related to #3772
But if toString is called right after creating SentryId, it wont help much of delaying this UUID cost.

[Angelodaniel]

@adinauer -> Please see comment from @kozaxinan

[adinauer]

Yeah, we should measure impact of this PR. I'm afraid this doesn't have the desired effect due to toString(), hashCode and equals being called early. Caching the value for toString() might have a bigger impact, thanks for the suggestion.
Changing how we use IDs (i.e. only generate them when sending) will be a bigger change and I'm not entirely certain it's possible. Offering a configurable ID generation mechanism might be the better approach. We'll discuss internally and update once we know more.

[lbloder]

@kozaxinan Good point, I'll rework SentryId to cache the resulting String instead of the UUID object.

As mentioned by @adinauer, measuring the performance impact of this change has yet to be done.

[kozaxinan]

Nice this will allow more improvement. Will this be ported to version 7?

[adinauer]

@kozaxinan we're planning to explore multiple options to improve the SDK. We can check which of those make sense to port to v7 when we know which ones we'll keep.

[stefanosiano]

just some cleanup, but looks good!
do we already know the impact of this change?

[lbloder]

@stefanosiano I did some tests regarding performance of this change and found another issue, that i fixed in a new commit, if you could take another look that would be great. The SentryFrameMetricsCollector caused lots of unnecessary toString calls to SpanId and thus triggered the UUID generation.

It does not change much in terms of startup time (as reported by Sentry) on a Motorola moto e22 low-end device with Android 12.

However, most of the calls that lead to UUID generation is now done on backround Threads:

8.x.x branch:

Test	Calls per Thread
Vanilla android-sample	{main:toString=16, SentryExecutorServiceThreadFactory-0:serialize=2}
android-sample with 1 TR and 100 Spans	{main:toString=420, SentryAsyncConnection-0:serialize=162}

Lazy branch:

Test	Calls per Thread
Vanilla android-sample	{main:toString=10, SentryExecutorServiceThreadFactory-0:serialize=2}
android-sample with 1 TR and 100 Spans	{main:toString=10, SentryAsyncConnection-0:serialize=105, SentryExecutorServiceThreadFactory-0:serialize=2}

[kozaxinan]

Will this be cheery picked to the current version?

[adinauer]

@kozaxinan we're working on releasing another beta for v8 and plan to have it GA soonish so we'd rather focus on v8 than backporting to v7 unless this is a blocking problem for someone.

[kozaxinan]

@kozaxinan we're working on releasing another beta for v8 and plan to have it GA soonish so we'd rather focus on v8 than backporting to v7 unless this is a blocking problem for someone.

I understand the process. But it is not clear when 8 will be available and when the general audience will migrate.
Considering the Christmas season is coming, this could be a nice improvement to the 7 version until we get version 8 next year.
It is not a blocker but on slow devices it impacts.

[adinauer]

v8 GA is planned for mid of December and upgrading should be straight forward. We've just released 8.0.0-beta.2 in case you want to give it a try and see for yourself how much effort upgrading is on your app(s).