Know when slow and frozen frames occurred during a transaction

[philipphofmann]

Description

Currently, the SDK attaches slow and frozen frames to transactions. The problem is that the users don't know when these slow and frozen occurred during the transaction. We could attach the slow and frozen frames to individual spans or we could add timing information as proposed in #1910, but then Sentry would need to do some work to add this somehow to the transactions. We could even add spans for slow and frozen frames.

Maybe only add to UI spans, because there could be two spans running at the same time. Furthermore, slow and frozen frames might not really make sense for file IO, DB, or network spans.

[brustolin]

We decided to create spans when a slow or frozen frame occurs.

[philipphofmann]

Wait for #1910 to get merged before tackling this PR because it tracks the timestamps of slow and frozen frames.

[philipphofmann]

FrameTimestamps are stored here

sentry-cocoa/Sources/Sentry/SentryFramesTracker.m

Line 31 in 62ea014

@property (nonatomic, readwrite) SentryMutableFrameInfoTimeSeries *frameTimestamps;

Tracer adds them to the profile here

sentry-cocoa/Sources/Sentry/SentryTracer.m

Lines 439 to 441 in 62ea014

	frameInfo = SentryFramesTracker.sharedInstance.currentFrames;
	[SentryFramesTracker.sharedInstance resetProfilingTimestamps];
	SentryFramesTracker.sharedInstance.currentTracer = nil;

[kevinrenskers]

@philipphofmann You explained the thinking behind this last week but now that I am looking into this, I am not sure how you wanted this to work.

• We want to add a span for every slow or frozen frame to the transaction, right?
• frameTimestamps contains the start_timestamp and end_timestamp of any slow or frozen frame. But how do we know if the frame was slow or frozen? If I loop over frameTimestamps, I have no clue what kind of frame it was? Adding a span with the text "slow or frozen frame" seems a bit weird?
• frameTimestamps doesn't seem to hold actual timestamps (as in, dates), but something different. So how can we create spans with timestamps, so that they are shown in the UI at the correct place?

Can we go over this together? Thanks!

[armcknight]

But how do we know if the frame was slow or frozen?

We talked about this in profiling but decided at the time we could compute this server-side, since we also send the expected framerates (as a time series since it can change on modern devices). But it would be easy to track them in separate arrays from each of these callsites: here and here.

And just so I understand what's ultimately being requested, I imagine we'd want to display something like this?

[kevinrenskers]

Check my PR where I had a working implementation using those callsites: #2028. But ultimately it doesn't result in a very useful thing in the Sentry UI, see comments in that PR as well.

[brustolin]

We're closing this based on the result of #2028.

[philipphofmann]

Reopened because of #2028 (comment)

[philipphofmann]

After investigating this feature, it turned out that it is not that useful. If a lifecycle method needs 200 ms to complete, and we put a slow frame span below it, it doesn't add extra value because you can assume that already if you see that you have one slow frame. By just looking at the raw numbers of slow and frozen frames, you know that you have to fix something, and you should keep an eye on the spans that took the longest time.