Mobile Performance Issues - Your feedback needed

[wmak]

Hi Folks! I’m an engineer at Sentry on the Mobile Developer Experience Team. We’re looking to expand the kinds of performance issues Sentry can detect to include more issues focused on what mobile developers care about. Our first foray into this is with the File IO on Main Thread Performance Issue, a pattern which can contribute towards Applications Not Responding (ANRs) / App Hangs.

Here are some situations we’re currently considering,

• VectorDrawables loaded before initial display
  • While Vectors use less storage, they come with a runtime overhead compared to rasterized images.
• Resource Initialization on the main thread before initial display
  • Resources should be initialized lazily, so that your application can reach its initial display as quickly as possible
• Unbatched Network requests
  • Each network request requires the wireless radio on your users device to power on, which comes with a performance overhead and consumes battery

Are these situations important to you, are there any missing from this list that you would like to see?

[shruthilayaj]

I really like the idea of connecting main/UI thread issues to ANRs if they contribute to them.

Is there potential to detect other slow operations on the main thread? It could be really useful if we could auto-instrument tagging spans that are running on the main thread and then just build detectors to detect "long running spans". I don't think we should create performance issues around these but if it leads to an ANR downstream, we could tie these spans back to the ANR event to give users more information on long running ops on the main thread that might have led to the ANR.

We often don't have transactions running when an ANR is triggered, so this might require persisting the trace id somehow and sending that with the ANR so we can connect them back in sentry.

[romtsn]

Resource Initialization on the main thread before initial display
Resources should be initialized lazily, so that your application can reach its initial display as quickly as possible

I'd be curious which resources do you mean exactly?

In general, the list looks good to me, all of them make sense. What I'd add on top:

• DB queries on the main thread (before initial display or after, doesn't matter)
  • Similar to File I/O on the main thread, but for database operations
• Key-Value Storage access on the main thread (before initial display or after, doesn't matter)
  • Similar to File I/O on the main thread, but for SharedPrefs (Android) and NSUserDefaults (Cocoa)
  • On Android, in addition, we could track if users call SharedPreferecnes.apply() on the main thread, as this is known for having problems
• Heavy Bitmap decoding on any thread
• This is more of profiling issues, but potentially we could detect any slow method call on the main thread, which is done pre-initial display. That is also a recommendation from Google - to initialize your app as lazily as possible.
• Heavy layout inflation
  • Potentially we could detect how deeply nested the layout is, or if there are some known problematic layouts are used, or in general if the layout inflation phase takes a while, we could create perf issues out of all of that.

[wmak]

Which resources do you mean exactly

Good question, that might be too vague for this. I was paraphrasing that from Android documentation here

I'm curious, is it expensive to parse the layout? Is that something we can measure consistently in transactions?

[romtsn]

Good question, that might be too vague for this. I was paraphrasing that from Android documentation here

ah ok, I guess I've expanded on this in my comment (bitmaps, layouts, etc.)

I'm curious, is it expensive to parse the layout? Is that something we can measure consistently in transactions?

Do you mean inflating the layout (as in, converting it from xml to actual views)? Yeah it can be expensive if the hierarchy is deeply nested or some deprecated layouts are used. We've just looked into this yesterday with @markushi and I think we can measure that for each view being inflated, but needs some investigation.

[wmak]

Re the layout, I was wondering if we can either do the linting mentioned here either in the SDK or the backend (probably not backend given sending the view hierarchy is expensive)

[eric]

I'm finding these "File IO on Main Thread" alerts to be unhelpful. Practically all of them are telling me that a .nib is being loaded, which is expected and not anything I can do anything about.

The only other ones that I'm being told about are when the app has received a notification that it is going to be suspended and I'm doing cleanup work including saving to disk. None of these things appear to be something I can avoid.

[wmak]

Thanks for the feedback! We've went back and forth whether to include .nib as part of the file io issue (see here). For now I've reopened the changes here while I gather more feedback on if we'll move forward with this change

Related to this though, would you like to see .plist and .string files removed from file io issues as well?

[eric]

Is there a domain expert or PM that could weigh in on this?

From my perspective: The point of Sentry is to tell me about actionable things that I can do something about to make my app better. Giving me alerts about situations that are fundamental to the way the platform I'm building on operates may teach me something about the infrastructure, but aren't things I can control. If I'm getting alerts for things I can't change, it just adds confusion and annoyance to my use of your product.

I have the same confusion with "App Hung" events that have no stack frames in my app. If this is the framework that is doing something that is hanging... there's not a lot that I can do about this, is there?

[zoesyc]

hey @eric -

We absolutely agree. We want to ensure that we're providing more signal than noise to your issues feed. With File IO being one of the newest performance issues we've introduced, we're still fine-tuning our detection.

Through customer feedback, we've realized that we cast a wider net than is necessary - including system and third-party calls that are inactionable for developers. So we're working toward capturing the File IO issues within application code.

To your point about "App Hanging" - we've integrated MetricKit (experimentally) to capture app hangs with stack traces directly from Apple. This should provide the necessary context to fix the issue. However, you are correct, without a stack trace, it can render this event to an alert more than an actionable issue.

@philipphofmann (and @indragiek, @kahest for context) I'm wondering if there's a way of filtering for app hangs that are specifically within application code?

Our goal with File IO and some upcoming mobile-based performance issues (e.g. DB queries in the main thread, JSON/ Image decoding in the main thread) is to simplify app hangs or display timing issues to their root causes. Provided accurate detection and context, it will reduce the effort and guess work for those issues. Any thoughts on this?

[philipphofmann]

Another user complained on Discord that he gets file I/O on the main thread for .plist files that originate from Apple, and he can't do anything about them. I agree with @eric that we should disable .plist files.

I want to keep AppHangs out of this discussion here. @eric already opened an issue getsentry/sentry-cocoa#2791, and there is another GH discussion on that topic getsentry/sentry-cocoa#2715.

[wmak]

Thanks Philipp, I'll remove .plist as well then 👍