-
-
Notifications
You must be signed in to change notification settings - Fork 435
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add capabilities to track jetpack compose composition/rendering time #2507
Conversation
|
Performance metrics 🚀
|
Revision | Plain | With Sentry | Diff |
---|---|---|---|
04675d0 | 244.33 ms | 318.90 ms | 74.57 ms |
cd0142b | 358.20 ms | 394.85 ms | 36.65 ms |
17a5b01 | 306.35 ms | 333.92 ms | 27.57 ms |
0ab9720 | 333.73 ms | 393.38 ms | 59.64 ms |
73d3f00 | 286.64 ms | 319.79 ms | 33.15 ms |
beae470 | 331.42 ms | 362.17 ms | 30.75 ms |
f0108ba | 323.04 ms | 370.94 ms | 47.90 ms |
118defd | 309.04 ms | 347.06 ms | 38.02 ms |
dda3459 | 355.41 ms | 426.02 ms | 70.61 ms |
App size
Revision | Plain | With Sentry | Diff |
---|---|---|---|
04675d0 | 1.73 MiB | 2.34 MiB | 625.74 KiB |
cd0142b | 1.73 MiB | 2.33 MiB | 620.68 KiB |
17a5b01 | 1.73 MiB | 2.34 MiB | 624.25 KiB |
0ab9720 | 1.73 MiB | 2.33 MiB | 620.68 KiB |
73d3f00 | 1.73 MiB | 2.34 MiB | 625.06 KiB |
beae470 | 1.73 MiB | 2.33 MiB | 620.91 KiB |
f0108ba | 1.73 MiB | 2.34 MiB | 625.63 KiB |
118defd | 1.73 MiB | 2.34 MiB | 626.08 KiB |
dda3459 | 1.73 MiB | 2.34 MiB | 625.63 KiB |
…va into feat/compose-tracing
Codecov ReportPatch coverage:
Additional details and impacted files@@ Coverage Diff @@
## main #2507 +/- ##
============================================
+ Coverage 81.21% 81.30% +0.08%
- Complexity 4152 4186 +34
============================================
Files 335 336 +1
Lines 15444 15484 +40
Branches 2011 2022 +11
============================================
+ Hits 12543 12589 +46
+ Misses 2108 2101 -7
- Partials 793 794 +1
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. ☔ View full report in Codecov by Sentry. |
sentry-compose/src/androidMain/kotlin/io/sentry/compose/SentryComposeTracing.kt
Outdated
Show resolved
Hide resolved
sentry-compose/src/androidMain/kotlin/io/sentry/compose/SentryComposeTracing.kt
Outdated
Show resolved
Hide resolved
sentry-compose/src/androidMain/kotlin/io/sentry/compose/SentryComposeTracing.kt
Outdated
Show resolved
Hide resolved
sentry-compose/src/androidMain/kotlin/io/sentry/compose/SentryComposeTracing.kt
Outdated
Show resolved
Hide resolved
sentry-compose/src/androidMain/kotlin/io/sentry/compose/SentryComposeTracing.kt
Outdated
Show resolved
Hide resolved
@Nullable String description, | ||
@Nullable SentryDate timestamp, | ||
@NotNull Instrumenter instrumenter) { | ||
return startChild(operation, description, timestamp, instrumenter, new SpanOptions()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
l
: just thinking if we should propagate the options of this span to the children, in case they are not provided? probably not
@@ -343,6 +397,44 @@ public void finish(@Nullable SpanStatus status) { | |||
@Override | |||
@ApiStatus.Internal | |||
public void finish(@Nullable SpanStatus status, @Nullable SentryDate finishDate) { | |||
|
|||
// auto-finish any open spans | |||
for (Span span : getSpans()) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
h
: as discussed internally, maybe let's try to create a new type for this kind of spans instead of introducing SpanOptions
and packing everything into SentryTracer
. There may be 2 different ways to solve this going forward:
- try to have
IdleSpan
withidleTimeout
which finishes itself after some timeout. This would require changing Activity txs totrimEnd = true
to have the correct end timestamp for them - try to have
IdleSpan
without the idle timeout, so we could just iterate here the same way we do now, and check if the span is instance ofIdleSpan
, and force-finish it. It would then do the trimStart/trimEnd logic inside its ownfinish
method.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@romtsn Sounds good, but I'm wondering how far I should go here? Spans right now are half-baked POJOs, e.g. a span can not directly access it's children. On the other hand a span has access to it's root transaction.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hmm, good point. Would you mind asking about that in team-client-infra
to see if anyone has concerns if we keep track of child spans in Span and not only in SentryTracer? For me it would be fine, but maybe there's something we should align on, or at least document.
Also, there's a SpanRecorder class available on JS. Not sure if it's exactly what we want to achieve, but maybe we could reuse some bits.
...es/sentry-samples-android/src/main/java/io/sentry/samples/android/compose/ComposeActivity.kt
Outdated
Show resolved
Hide resolved
Co-authored-by: Roman Zavarnitsyn <[email protected]>
@@ -1742,7 +1750,7 @@ public final class io/sentry/SentryTraceHeader { | |||
|
|||
public final class io/sentry/SentryTracer : io/sentry/ITransaction { | |||
public fun <init> (Lio/sentry/TransactionContext;Lio/sentry/IHub;)V | |||
public fun <init> (Lio/sentry/TransactionContext;Lio/sentry/IHub;ZLio/sentry/TransactionFinishedCallback;)V | |||
public fun <init> (Lio/sentry/TransactionContext;Lio/sentry/IHub;Lio/sentry/TransactionOptions;Lio/sentry/TransactionFinishedCallback;)V |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
m
: technically a breaking change, but I doubt anyone ever used that. Should we remove it altogether and just use the other ctor in the ActivityLifecycleIntegrationTest?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that's fine as SentryTracer
is ApiStatus.Internal
|
||
final @NotNull List<Span> children = getChildren(); | ||
for (final Span child : children) { | ||
if (child.getParentSpanId() != null && child.getParentSpanId().equals(getSpanId())) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
m
: we don't need this check, because we already do it in getChildren
, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm, great stuff! 👍
left some comments. Also there's one more point from the previous iteration - to surround the testTag
with a boolean flag, which is turned on by default.
Instead of immediatelly finishing the transaction in onPostResume, this way delayed JPC spans can be properly created
@@ -345,8 +352,30 @@ public void finish(@Nullable SpanStatus status) { | |||
@Override | |||
@ApiStatus.Internal | |||
public void finish(@Nullable SpanStatus status, @Nullable SentryDate finishDate) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@adinauer wanna take a look at this, if it has any effect for backend? I don't think it does, but just to make sure we do not introduce some new potential memory leak or something
sentry-android-core/src/main/java/io/sentry/android/core/ActivityLifecycleIntegration.java
Show resolved
Hide resolved
a couple of minor things, but looks good after the final pass! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Didn't see any obvious problems.
…2507) Co-authored-by: Roman Zavarnitsyn <[email protected]> Co-authored-by: Sentry Github Bot <[email protected]>
📜 Description
Add capabilities to track compose composition/rendering time. This requires some changes to our span interface.
Since composition and rendering has no clear start and end, we'd need to have spans
💡 Motivation and Context
In terms of performance monitoring we want to track
💚 How did you test it?
📝 Checklist
sendDefaultPII
is enabled🔮 Next steps