The Sentry Android SDK is now 20-30% faster!

Our team has been working hard over the last quarter to make sure Sentry's Android SDK is faster for you. During this time, we reduced the Android SDK init time by 20-30%. We also reduced memory allocation, fixed memory leaks, and reduced background CPU time by up to 10%.

We measured that 20-30% improvement from version 8.43.0 to 8.54.0 by measuring the duration of SentryAndroid.init. This is the work on the critical path of your application's startup. Just to clarify, this isn't the full app startup time and this was measured with a synthetic demo app. However, we also asked some of our customers to try these new versions and run benchmarks, and they have also reported similar startup performance findings to our 20-30% startup time improvement. (Apps are all very different and use different Sentry features, so we feel the need to point out that real world performance may differ.)

The Sentry SDK is super popular! We have roughly 4.5 billion app starts per day across sentry-react-native, sentry-java and sentry-flutter (sentry-flutter and sentry-react-native include sentry-java). Around 50% of app starts are cold starts. We can conservatively estimate that the 25% cold start time reduction leads to an average savings of 10ms. Using that data, we will save users and CPUs 6,250 hours per day, which translates to roughly 2.3 MWh per year. That's roughly 1/5 of one US household's yearly electricity consumption or, for our EU readers, roughly 2/3 of an EU household's electricity consumption.

How did we achieve this? We measured bottlenecks in the SDK using Perfetto traces. We dove into customer-reported performance issues and memory leaks in our backlog. Of course, we also used our favorite LLMs (yup, it's 2026 after all) to analyze the startup path together with the Perfetto agent skill. We made over 40 different changes to improve the performance of the Sentry Android SDK. With every change, we benchmarked it with our new Android Macrobenchmark setup to see if the changes led to a statistically significant performance improvement.

Tip: Please report performance issues (or any other issue in our SDK) by creating a new issue in the sentry-java repo on GitHub so we can keep improving! Include Perfetto traces when possible.

In a world where gobs of code are bogging down codebases, the easiest way to speed up your app is simply to bump up the Sentry Android SDK version to the latest. In order to benefit from these improvements, please use the latest version of the Android SDK (at least 8.54.0 for performance improvements) together with the latest version of the Sentry Android Gradle Plugin (at least 6.20.0 for performance improvements). And please send us your feedback on how it affects your app's startup performance! We'd love to hear it.

If you're curious what changed under the hood, we'll highlight just a few of the 40 changes we made. For the full list, please read the Performance section of the changelog entries between release 8.43.2 and release 8.54.0.

Resolving manifest data at build time

The Sentry SDK allows you to set options in the Android Manifest. Parsing the manifest is notoriously slow and certainly much slower than reading options from bytecode. To speed this up, we write the options from the Sentry Android Gradle Plugin into the app's bytecode at build time. When the SDK detects the options are set in the bytecode, it skips reading the manifest entirely. This alone in benchmarks led to a 6.5% improvement. See sentry-java #5976 and sentry-android-gradle-plugin #1405 for more details.

We also did this for class availability, instead of using reflection to determine if the classes were available, since reflection is slow. See sentry-java #5875 and sentry-android-gradle-plugin #1404.

Faster DSN parsing

java.net.URI is notoriously slow and handles many edge cases that we don't need. When benchmarked, it could take up to 6ms, blocking the SDK init time. We replaced it with a lighter weight custom DSN parser that on the same benchmark took just 1µs (~6000x faster). See sentry-java #5448 for more details.

Moving threads to shared executor pools

Threads in ART (Android Runtime) will dedicate a 1MB stack to each thread. There were several places in the SDK where we were creating one-off threads instead of re-using our shared executor pools. The fix here is straightforward: use our existing thread executor pools instead. The hard part is verifying that the code is still correct.

We did this in 3 places in the code, which reduces our SDK heap size by 3MB in addition to the savings of not initializing and garbage collecting these threads. See sentry-java #5670, sentry-java #5819, and sentry-java #5814.

Benchmark notes

• Benchmarks were run using the published versions of Sentry 8.43.0 and 8.54.0 using SAGP 6.20.0 on a Pixel 3 with locked clocks using our macrobenchmark.
• Some modifications to the demo app were made to make the two versions compatible and add an android.os.Trace to measure the same thing in both versions.
• 4 interleaved rounds with 10 runs per round for a total of 40 rounds per version.

If you're new to Sentry, you can sign up for Sentry and refer to the docs to get started with the Sentry Android SDK.