Skip to content

Reduce logging allocation overhead on the init path #5700

Description

@runningcode

Problem

Two compounding issues:

  1. ManifestMetadataReader's read helpers build the debug message eagerly — logger.log(DEBUG, key + " read: " + value) (sentry-android-core/src/main/java/io/sentry/android/core/ManifestMetadataReader.java:750-800). With ~101 metadata reads per init, that is ~100+ StringBuilder/String allocations (plus explicit boxing in readDouble, :794-796) thrown away when debug=false (the default), because DiagnosticLogger filters after the string was built at the call site.
  2. Init overall emits 150+ logger.log(DEBUG, ...) calls; the varargs overloads allocate an Object[] per call even when filtered.

Proposal

  • Guard the metadata read helpers with one options.isDebug() / logger.isEnabled(DEBUG) check, or pass format + args instead of concatenating.
  • Consider an isEnabled fast path at the hottest init call sites, or making the debug=false logger path allocation-free.

Pure allocation/GC-pressure win; not individually measurable on cold start (#5679 noise floor), verify via ART allocation trace.

Related: JAVA-652 / #5477 would remove the runtime manifest parse entirely; this is the cheap runtime fix in the meantime.

Metadata

Metadata

Assignees

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions