IssueTracker

I'd prefer we say method tracing is always on during the measurement in macrobenchmarks (assuming you use macrobench to start/kill the process)

When a process is being started is not entirely obvious to an app developer. Additionally, method traces collected during startup are actually very important; so we need to make that part easy. Which is why startActivityAndWait(...) signals a method trace start (when StartupMode.COLD is being used), and the end of the measurement is when a method trace ends.

What scenario do you have in mind that you'd want the method tracing for startup, but it wouldn't be covered by the startActivityAndWait or measureBlock?

If I have

startupMode = COLD
setupBlock= {
 // prepare something
}
measureBlock = {
 startActivityAndWait()
}

I would say I still want to only see the method trace of what I'm measuring.

If I have

startupMode = COLD
setupBlock= {
 startActivityAndWait()
}
measureBlock = {
  // do something in the app
}

This doesn't work, because the process is killed between setupBlock and measureBlock.

I can have something like

startupMode = COLD
setupBlock= {
 sendABroadcastWhichWakesTheProcess()
}
measureBlock = {
 startActivityAndWait()
}

But I would still expect the method trace to run in the measureBlock? The process would be killed after setupBlock anyway, so the method trace can't really survive, can it?

Maybe I'm missing some scenario though.

Summarizing an offline convo about how we plan to do this:

• at beginning of measure block:
  • start method tracing if process alive
• (in measure block) process started
  • start process with method tracing
• (in measure block) process killed
  • flush method trace before kill
• at end of measure block:
  • flush method trace

No special handling for startup modes, or tracing of the setup block.

This requires a lot of checking process state, but that should only happen while method tracing, so it's worth the cost to get predictable tracing.

Note that you'll potentially get arbitrary numbers of traces depending on how many instances of the process run sequentially.

I think that SG. I think the arbitraty numbers of traces is fine, because these probably matter only for further analysis.