Chrome Trace在Runtime执行的关键路径上嵌入trace记录，提供了深入分析应用程序调度逻辑的能力。在出现性能异常时，可以通过分析trace日志，快速找到异常发生的时间点。 注：使用Chrome Trace会带来少量的性能损耗。
1 日志生成
// 板端配置环境变量
export _HB_DNN_LOG_LEVEL_=1
export _HB_DNN_LOGGING_PATH_=log.txt
// 用户执行模型推理程序
// 当前目录会生成log.txt
// 日志内容过滤
cat log.txt|grep Trace |awk -F "Trace] " '{print $2, ","}' > trace.txt
// 日志格式调整
trace.txt开头加[且末尾把,改成]
2 trace.txt日志示例
[{"args":[{"core_id":1,"current_fcs_core_id":0,"custom_id":0,"desc":"input_2_concat","estimate execute time":107166,"execute fc time":0,"finish task time":0,"priority":0,"schedule start time":0,"submit fc time":0,"submit task time":1298463567925,"task_id":0}],"name":"TaskSubmit","ph":"i","pid":9067,"tid":0,"ts":1298463567926} ,
{"args":[{"core_id":1,"current_fcs_core_id":0,"custom_id":0,"desc":"input_2_concat","estimate execute time":107313,"execute fc time":0,"finish task time":0,"priority":0,"schedule start time":0,"submit fc time":0,"submit task time":1298468893235,"task_id":49}],"name":"UserCallWait","ph":"i","pid":9067,"tid":49,"ts":1298468893344} ,
......
{"args":[{"core_id":1,"current_fcs_core_id":1,"custom_id":0,"desc":"","estimate execute time":107313,"execute fc time":1298469000953,"finish task time":1298469001406,"priority":0,"schedule start time":1298468893357,"submit fc time":1298468894309,"submit task time":1298468893235,"task_id":49}],"name":"TaskRelease","ph":"E","pid":9067,"tid":49,"ts":1298469001728}]
3 网页查看
chrome浏览器打开网页 chrome://tracing/ edge浏览器打开网页 edge://tracing/ 之后加载trace.txt文本文件，可于浏览器中查看调度过程 网页快捷键：w放大，s缩小，a左移，d右移
4 调度示例
4.1 全BPU模型单线程perf
每行表示一个推理任务的执行情况，绿色长条ExecuteFC表示Runtime下发了BPU推理任务（但有绿条不表示BPU一定被这个绿条占用）。
在BPU推理前后，各有一些需要CPU处理的工作，比如提交任务，准备并下发FunctionCall，资源释放等，耗时较少。
4.2 全BPU模型多线程perf
多线程下，可以看到任务执行顺序不可控，且耗时有长短，需要注意的是，每个模型本身占用BPU推理的时间是差不多的，之所以绿条长短不一，是因为提交BPU推理任务到真的执行了BPU推理的这段等待时间，也被计算进了绿条内部（对应上文中说的有绿条不表示BPU一定被这个绿条占用），这也就是多线程perf的latency差异较大的原因。
4.3 有CPU算子模型的单线程perf
红色部分即表示CPU计算的算子。
4.4 有CPU算子模型的多线程perf
可以看到，某个线程的模型在执行CPU计算的时候，其他线程的模型会执行BPU计算，从而在多线程下，CPU的耗时被隐藏，因此模型有CPU算子时，单线程perf和多线程perf的结果差异会很大。