Open gkraynov opened 7 years ago
I tried adding this metric to a startup benchmark and got this error:
Exception: TraceImportError: Slice Looper.dispatchMessage end time is before its start.
at SliceGroup.endSlice (/tracing/model/slice_group.html:197:15)
at AndroidParser.traceMarkWriteAndroidEvent (/tracing/extras/importer/linux_perf/android_parser.html:145:43)
at FTraceImporter.traceMarkingWriteEvent_ (/tracing/extras/importer/linux_perf/ftrace_importer.html:814:14)
at FTraceImporter.eval (/tracing/extras/importer/linux_perf/ftrace_importer.html:832:14)
at FTraceImporter.forEachLine_ (/tracing/extras/importer/linux_perf/ftrace_importer.html:914:17)
at FTraceImporter.importCpuData_ (/tracing/extras/importer/linux_perf/ftrace_importer.html:821:12)
at FTraceImporter.importEvents (/tracing/extras/importer/linux_perf/ftrace_importer.html:352:12)
at importer (/tracing/importer/import.html:198:65)
at task.subTask (/tracing/importer/import.html:145:32)
at Task.run (/tracing/base/task.html:80:50)
I don't see this metric used anywhere, so I guess it bitrotted? What is the plan for it? Is it still important to have it?
hmm .. actually the stack trace does not look specific to this metric, let me check ..
right, it is the side effect of enabling options.config.enable_atrace_trace = True
As discussed with Android people we are going to implement some timeline-based metrics for Android systrace. It aimed to provide meaningful numbers in TraceViewer while exploring Android trace and should reduce human analysys time.
At the moment we have implemented 2 metrics (not landed yet):
Next step would be a metric which will measure "disk I/O" activity, but it requires additional information in the trace which is a blocker in some sense.
Let's keep this "bug" as a tracker for related changes.