IssueTracker

Method traces are < 10 M for activity startup cases (~10s CUJ).

I expect startup cases we have are pretty trivial. What about scrolling cases?

introduce a phase

I don't know if I like that as the default, for method tracing or for sampling in macrobench, since tests are usually so much longer than micro. Consider a 5 min scrolling test, where you're just not collecting profiling results for minutes on end while the developer waits.

Could always eventually make it an option like androidx.benchmark.profiling.primaryMeasurePhase.enable

Chris suggested I share some feedback from my recent try to have method tracing for the macro bench run. I was running a compose TrivialListScrollBenchmark I added

android { 
   defaultConfig {
     testInstrumentationRunnerArguments["androidx.benchmark.profiling.mode"] = 'MethodTracing'
   }
}

Into gradle and made a run. Each iteration created two files:

1. perfetto-trace which only contains the manually added traces (as if MethodTracing wasn't enabled)
2. method.trace files. a file for the 0th iteration contains some trace which I can open in studio or https://profiler.firefox.com, but I don't understand what part of the execution was tested. it shows a trace for a one Choreographer.doFrame where we composed a new item, but the whole run includes many frames for multiple flings and I am not sure what frame it chose. another interesting part is that method.trace files for each other iteration are just zero sized files Attaching those files

I landed this change to make this more consistent.

https://android-review.git.corp.google.com/c/platform/frameworks/support/+/2724235

--

In general, MethodTracing when enabled captures the time between a cold start to the point where the iteration is complete. We only turn on method tracing for iterations that involve cold starts. You will therefore not see a 1-1 mapping between the number of iterations and the number of method traces given you might be measuring HOT starts for e.g.

I fixed the issue where you were seeing 0 byte method trace files as well. Let me know if you have other questions.

I'm going to do one more pass on the behavior here to make it match micro more closely for the final 1.2 version:

• One method tracing pass at the end, after measurements, with measurements disabled (may want to still throw if no metrics captured, though)
• Document behavior surprises for micro vs macro
  • Starts in first startActivityAndWait for now
  • Add warning to output about why missing in living process case

With the above fix, macrobench method tracing is in a good enough/experimental state to ship with 1.2, so punting further work to 1.3

Remaining issues / gaps between method tracing in micro vs macro:

• Method trace should be done in separate measurement phase, more like microbench
• Method tracing can only start for an iteration if process is launched cold, so only one occurs frequently, e.g. when measuring warm start (CL in #comment12 adds warning about this)
• Method trace not embedded into perfetto trace

Bugjuggler: wait 1 week

Last thing here should be to not capture metrics (or at least label metrics separately) for method tracing iterations.

The following release(s) address this bug.It is possible this bug has only been partially addressed:

• androidx.benchmark:benchmark-macro:1.3.0-alpha05