0

I'd like to use traceview to measure performance for several asynchronous events. The asynchronous events are passed to me in a callback that looks similar to the below code.

interface EventCallback {

    void onStartEvent(String name);

    void onStopEvent(String name);
}

where every asynchronous event will start with a "onStartEvent" call and end with an "onStopEvent" call.

I'd like to create trace files for every event. From my reading here (http://developer.android.com/tools/debugging/debugging-tracing.html#creatingtracefiles), it's not possible to trace asynchronous events since the ordering of the calls must be "structured" in a "stack" like ordering. So, the call to "Debug.stopMethodTracing()" always applies to the most recent call to "Debug.startMethodTracing("calc");"

So, if I receive callbacks in the following order.

onStartEvent(A)

onStartEvent(B)

onStopEvent(A)

onStopEvent(B)

which will get interpreted to

Debug.startMethodTracing("A");

Debug.startMethodTracing("B");

Debug.stopMethodTracing(); // will apply to "B" instead of "A"

Debug.stopMethodTracing(); // will apply to "A" instead of "B"

Using traceview, is there anyway to do what I want? i.e. trace "non-structured" asynchronous events?

Jon
  • 1,381
  • 3
  • 16
  • 41

1 Answers1

1

traceview might be the wrong tool. If you really want to go this route you can keep an "active event count", and keep the tracefile open so long as there is an event being handled. This can result in multiple events being present in the same trace file, but you're tracing method calls in the VM, so there's no simple way around that.

If your events happen on different threads, you could separate them out with a post-processing step. This would require some effort to parse the data and strip out the undesirable records. (See e.g. this or this.)

You don't really say what you're trying to measure. For example, if you just want start/end times, you could just write those to a log file of your own and skip all the traceview fun.

Depending on what you're after, systrace may be easier to work with. Unfortunately the custom event class (Trace) only makes the synchronous event APIs public -- if you don't mind using reflection to access non-public interfaces you can also generate async events.

Community
  • 1
  • 1
fadden
  • 51,356
  • 5
  • 116
  • 166
  • Thanks for the help. I am interested in capturing the performance. I am noticing that certain events take longer than others and I'd like to not only figure out how long they take but also what is causing the issues. I tried systrace but it didn't seem to give me the information I needed from traceview. – Jon May 11 '16 at 23:34
  • Note that I am expecting the events to all take around the same time but for some reason, some events take much much longer. When I loaded up my trace in "systrace", it didn't show me the method profiling information like "traceview" does. Instead, it just draws the timeline for each of my "sections" and shows me what system activity occurred. – Jon May 11 '16 at 23:53
  • 1
    traceview tells you how long each method takes, in a single app. systrace tells you everything that's happening in the entire system, including which thread is scheduled on which CPU core (see e.g. http://bigflake.com/systrace/). If you captured "long" and "short" events you could compare the two to see if the slow one was interrupted by some other process, or just took a long time to execute. traceview is easier to use when you want to know what part of your program is using up all the time, but systrace lets you see more deeply into the system. – fadden May 12 '16 at 00:37