[meta] Profiling improvements for Firefox on Android
Categories
(Core :: Gecko Profiler, task, P2)
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.
Reporter | ||
Updated•5 years ago
|
Reporter | ||
Comment 1•5 years ago
|
||
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?
Reporter | ||
Comment 2•5 years ago
|
||
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)
Comment 3•5 years ago
|
||
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
Updated•3 years ago
|
Updated•1 year ago
|
Comment 5•1 year ago
|
||
Notes from discussion on 27/06/24 about priorities for this bug: https://docs.google.com/document/d/1qx-LfK925DSzBmWnFkq3N3L0lct0Q_8E_bTSqetC5Xk/edit?usp=sharing
Description
•