Sampling Profiler & Rogue case of App Profiling | by Akash Khunt | Mar, 2023 | Path Tech

This can be a publish on how a false constructive efficiency challenge (i.e. Important thread idle for ~1 second throughout software startup) brought about me to spend many days debugging and figuring out the foundation trigger. This challenge was solely seen when profiling a launch construct, and that too is on a tool that was restricted in reminiscence (RAM) and CPU energy.

Background

First let’s cowl some background. In the event you’ve lately tried profiling an Android app to determine/debug some efficiency points or simply to seize startup time metrics, you is perhaps acquainted with a quite common however very helpful advice that you must at all times create a profile. profile. launch construct

The rationale behind the use launch is constructed whereas it’s outlined is that debug The builds incur vital and various efficiency degradation, and aren’t helpful for timing precisely. This efficiency degradation will be attributed to one of many many debugging construct capabilities that enables builders to connect a debugger at any time, which requires monitoring of many issues, comparable to reminiscence and stack traces.

However since launch builds are supposed to be non-debuggable and better performing, they do not monitor something out of the field and are subsequently not profilerable. To handle this challenge, the Android workforce launched profileable manifest configuration in API 29, which is secure to maintain even throughout launch builds, permitting us to profile a launch construct with a lot much less efficiency overhead and minimal concern about information publicity, as construct instruments Host profiles and the shell course of can’t learn information from reminiscence.

The query

I confronted this essential thread idle challenge after I was profiling our app on totally different units of gadgets to scale back chilly begin time. To get the beginning time (i.e., TTID & TTFD) I created a macro reference level module in my app. The great thing about macrobenchmark testing is that it additionally generates systrace recordsdata that you should utilize to grasp what totally different threads are doing at any given time. From the take a look at outcomes, I discovered a few of the bottlenecks, one of many largest ones was the person attribution callback, which concerned a community name that contributed 20%-25% of the TTFD time. .

The issue right here was that we have been making the Person wait till we acquired the decision attribution information from the community. From systrace information at a low degree (2GB RAM) we additionally noticed that the primary thread was idle for ~1 second 😲 as you may see within the screenshot under.

Word: The identify of the primary thread might be hidden for confidentiality of the applying.

This appeared like a straightforward win to scale back chilly begin time, so we began dialogue with our product workforce and acquired approval to proceed with deferred dealing with of the attribution callback, i.e., permit the person to proceed to our house web page with out blocking it.

Very attentive eyes may need additionally seen from the systrace screenshot above that Jit Thread Pool it is also operating for a good period of time which will be considerably decreased by integrating Reference profiles. 🙂

After making the suitable change, we ran the checks once more and noticed that our TTFD time was decreased by ~20% on a high-end system (8 GB RAM and Android 13), however on a lower-end system (2 GB RAM and Android 10) it was nonetheless very related. As a primary troubleshooting step, we ran the startup time take a look at once more (like many issues in life, the primary troubleshooting step is at all times to retry the failed step 😉) however the end result was the identical 😅.

I then ended up spending just a few days figuring out the problem that is perhaps inflicting the primary thread to hold for 1 second, however discovered nothing. Then someday, I used to be randomly taking a look at what every of the threads spawned by our software was doing when the primary thread went to sleep and I lastly discovered the offender. he was the Sampling Profiler the thread that for some cause solely appeared alive for 1 second (precisely on the similar time the primary thread went to sleep), the place more often than not it was additionally sleeping, as proven within the screenshot under.

By reviewing the traces of the Sampling Profiler thread, I found that it was primarily performing two operations which have been Connect present thread & Detach CurrentThread As proven under.

I additionally tried transferring quite a lot of code right here and there to see if there have been any particular situations that might result in beginning this Sampling Profiler thread, a really obscure correlation I noticed was each time the primary thread appeared idle for just a few hundred milliseconds. , the Sampling Profiler was spawning to do its job.

Just like the identify “Sampling Profiler” means that it appeared to be performing some profiling associated work, so we concluded that it should not have an effect on precise person periods. However since we nonetheless wished to make certain, I eliminated the <profileable> aspect of the Manifest file to make sure that the applying is just not even profileable when capturing the traces. And the way did I take away the aspect? I could not run benchmarking checks appropriately anymore, so I ended up utilizing Seize/Log Monitor possibility current in developer choices to seize the hint file. And after wanting on the hint recordsdata, we confirmed that the 1s essential thread grasp challenge is lastly gone 🙌.

Conclusion

Though it was including 1 second delay on a lot of the macro timing metrics i.e. TTID and TTFD, it’s not doable to maintain it eliminated as it is vitally a lot wanted to run the benchmarking checks. So we lastly got here to the conclusion that earlier than utilizing any sort of macro time metric on low-end gadgets, we’ll take away 1s from the reported time (after parsing the hint recordsdata).

I hope this publish saves you just a few hours if not days debugging an issue that does not even have an effect on actual customers 🙂.