You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
SentryExecutorService is single-threaded, and prewarm() is submitted ahead
of loadLazyFields() during init, so its 40-task schedule/cancel/purge loop
cannot reduce first-task latency — it can only delay it. The thread creation
and executor class loading it aimed to warm are paid identically by the first
real task (loadLazyFields), which is submitted unconditionally right after,
so prewarm warms nothing that would not already be warmed.
On-device A/B benchmarks on a Galaxy A55 (Android 16) show no measurable
first-useful-task speedup from prewarm and ~20us of extra background-thread
work. Remove prewarm() from ISentryExecutorService and its implementations
and from both init call sites.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Copy file name to clipboardExpand all lines: CHANGELOG.md
+2Lines changed: 2 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -17,6 +17,8 @@
17
17
18
18
- Skip `Hint` allocation in `Scope.addBreadcrumb` when no `beforeBreadcrumb` callback is set ([#5689](https://github.com/getsentry/sentry-java/pull/5689))
19
19
- Speed up scope persistence by detecting the Sentry executor thread via a marker instead of a `Thread.getName()` name scan on every scope mutation ([#5691](https://github.com/getsentry/sentry-java/pull/5691))
20
+
- Remove executor prewarm during SDK init ([#5681](https://github.com/getsentry/sentry-java/pull/5681))
21
+
- The single-threaded `SentryExecutorService` queued the prewarm work ahead of the first useful task, so it could only delay init work, never speed it up; the thread and class loading it warmed are paid identically by the first real task submitted right after.
0 commit comments