Open Bug 1616887 Opened 5 years ago Updated 2 months ago

[meta] Profiling improvements for Firefox on Android

Categories

(Core :: Gecko Profiler, task, P2)

task

Tracking

()

People

(Reporter: Harald, Unassigned)

References

(Depends on 17 open bugs)

Details

(Keywords: meta)

Set of bugs to improve the gecko profiler for Firefox/GeckoView on Android.

Blocks: 1616622
No longer blocks: 1616622
Depends on: 1616622, 1616642
Depends on: 1341811

Via :mstange in https://github.com/firefox-devtools/profiler/issues/2475

The Fenix team is interested in using the Firefox profiler more. However, as I understand it, they aren't necessarily interested in the Gecko data, they're mostly interested in using the UI, and using it to understand regressions in automation perf tests. The data sources would be Java/Kotlin stacks and manual marker instrumentation in the Java/Kotlin code.

We should find out what we can do to make their lives easier.

The following questions come to mind:

  • What automated performance tests does Fenix use? Which test harnesses do these run in? Which of them support Gecko profiling already? Which of them can capture Android traces? Which of them do we want to get profiles from?
  • What are examples of manual instrumentation / markers that the Fenix team is thinking about adding?
  • How much Gecko data is needed? Do these profiles require having both Java/Kotlin markers and Gecko things on the same timeline? Or should we treat this as an entirely new data source?
  • Apparently nimbledroid automatically generated some kind of profiling data. What type of profile did it generate (example profile?)? What needs to be done to generate similar data in our non-nimbledroid test harnesses?

Via mcomella

  • I've heard profiling startup is hard
  • In debuggable=true builds, reported JVM performance is not very trustworthy. I've heard the Profiler can run on debuggable=false builds: it could be cool to warn devs if the build is debuggable about this (note: the AS profiler doesn't support profiling without debuggable=true)
  • In my experience with the Android profiler working on startup, I also wish it told me:
    • Which methods are touching the disk
    • When is the CPU bottlenecked (i.e. maxed out across all cores)? We have many tiny tasks across many different threads but these don't map to cores so it's hard to determine where bottlenecks occur except in theory
    • When are new threads created (so I can determine what impact that's having on startup)

Another list from Markus:

  • it doesn't start early enough
  • it might have a bit more overhead than the android sampling profiler, but we haven't measured that
Depends on: 1631831
Depends on: 1624993
Depends on: 1615066
Depends on: 1631928
Depends on: 1638889
Depends on: 1641119
Depends on: 1641122
Severity: normal → S3
Depends on: 1892641
Depends on: 1735897, 1581963
Depends on: 1635810
Duplicate of this bug: 1435934
Depends on: 1623942
You need to log in before you can comment on or make changes to this bug.