perfetto-trace-analysis

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Resources

资源

Domain Hints: Reference files for specific performance areas:
```
CPU
```
,
```
Graphics
```
,
```
I/O
```
,
```
IPC
```
,
```
Memory
```
,
```
Power
```
. These files each contain multiple expert-vetted, powerful trace analysis techniques to steer and aid in the analysis.
Perfetto SQL Reference: Reference guidelines for translating intents into valid queries are located in the SQL reference. You must read this reference and follow its Execution Protocol for all SQL generation.

领域提示： 针对特定性能领域的参考文件：
```
CPU
```
、
```
Graphics
```
、
```
I/O
```
、
```
IPC
```
、
```
Memory
```
、
```
Power
```
。这些文件包含多种经专家验证的高效追踪分析技术，可为分析提供指导和支持。
Perfetto SQL参考： 将需求转换为有效查询的参考指南位于SQL参考文档中。您必须阅读此参考文档，并在所有SQL生成过程中遵循其执行协议。

Setup Phase (Mandatory)

设置阶段（必填）

Initialize Scratchpad (Chain of Evidence):
- Maintain your working memory in a local scratchpad file located in the exact same directory as the target trace file.
- Name the file using the trace's filename appended with
```
_analysis.md
```
  (e.g.,
```
[trace_filename]_analysis.md
```
  ). Before creating it, check if a file with that name already exists by listing the directory's contents---to avoid biasing your investigation, DO NOT read the file's contents to check for its existence. If it does, append an incrementing version number (e.g.,
```
_v2.md
```
  ,
```
_v3.md
```
  ) until you find an available filename. You MUST hardcode this exact filename in all subsequent tool calls.
- Use this scratchpad STRICTLY to log verified facts: timestamps, slice names, thread IDs (utid/tid), and thread states.
- DO NOT write preliminary hypotheses or premature conclusions in the scratchpad. It is a strict Chain of Evidence.
Review Domain Hints: Read the Domain Hints in each file to get a high-level overview of what techniques are possible. Make sure to use this baseline knowledge when researching and retrieving hints during the ongoing investigation.
Review SQL Reference: Read the SQL reference in
```
references/sql.md
```
and follow its Execution Protocol for all SQL generation. Do not guess schemas.
Target Resolution: If the user's request is broad (e.g., "why is the app slow?") and doesn't specify a package name:
- Execute a query to identify the active application:
```
sql INCLUDE PERFETTO MODULE android.startup.startups; SELECT package FROM android_startups;
```
- If multiple packages are returned, ask the user to choose one. Save the chosen
```
package_name
```
  to your scratchpad.

初始化暂存文件（证据链）：
- 在目标追踪文件所在的同一目录中，维护一个本地暂存文件作为工作内存。
- 文件命名规则为追踪文件名后追加
```
_analysis.md
```
  （例如：
```
[trace_filename]_analysis.md
```
  ）。创建前，需列出目录内容检查该文件名是否已存在——为避免影响调查客观性，请勿读取文件内容来判断是否存在。若已存在，则追加递增版本号（例如：
```
_v2.md
```
  、
```
_v3.md
```
  ），直到找到可用的文件名。后续所有工具调用中必须硬编码此确切文件名。
- 此暂存文件仅用于记录已验证的事实：时间戳、切片名称、线程ID（utid/tid）和线程状态。
- 请勿在暂存文件中写入初步假设或过早结论。它是严格的证据链。
查看领域提示： 阅读各文件中的领域提示，全面了解可用的分析技术。在持续调查过程中研究和检索提示时，请务必利用这些基础认知。
查看SQL参考： 阅读
```
references/sql.md
```
中的SQL参考文档，并在所有SQL生成过程中遵循其执行协议。请勿猜测数据库模式。
目标确定： 如果用户的请求较为宽泛（例如：“应用为什么运行缓慢？”）且未指定包名：
- 执行查询以识别活跃应用：
```
sql INCLUDE PERFETTO MODULE android.startup.startups; SELECT package FROM android_startups;
```
- 如果返回多个包名，请让用户选择其一。将选中的
```
package_name
```
  保存到暂存文件中。

Investigation Protocol

调查流程

Follow this iterative loop until you have isolated the definitive root cause(s):

遵循此迭代循环，直到确定明确的根本原因：

1. Formulate Hypothesis

1. 提出假设

Prioritization: Form hypotheses using information from: user prompt > "Domain Hints" (
```
CPU
```
,
```
Graphics
```
,
```
I/O
```
,
```
IPC
```
,
```
Memory
```
,
```
Power
```
) > general knowledge. Be sure to leverage these "Domain Hints" as they are expert-vetted analysis techniques.
Source Attribution: Explicitly mention the source of your hypothesis (e.g., "Based on hints_io.md...").
Focus Constraint: Focus on the primary bottleneck. Avoid investigating deep into binder transactions unless the user explicitly asks for it or there is no other obvious bottleneck.
State Reasoning: Briefly state your reasoning based on previous findings before generating a new query.

优先级： 利用以下信息提出假设：用户提示 > “领域提示”（
```
CPU
```
、
```
Graphics
```
、
```
I/O
```
、
```
IPC
```
、
```
Memory
```
、
```
Power
```
） > 通用知识。请务必利用这些“领域提示”，因为它们是经专家验证的分析技术。
来源说明： 明确说明假设的来源（例如：“基于hints_io.md的内容...”）。
聚焦约束： 聚焦于主要瓶颈。除非用户明确要求，或没有其他明显瓶颈，否则请勿深入调查binder事务。
推理说明： 在生成新查询之前，简要说明基于之前发现的推理过程。

2. Plan and Collect Data

2. 规划并收集数据

Metrics First: Start with a high-level view using trace metrics before diving into custom SQL (e.g.,
```
./trace_processor --run-metrics android_startup
```
).
Broad to Narrow: Begin with broad queries using minimal filters. Favor fuzzy matching (e.g.,
```
GLOB '*abc*'
```
) over exact matching.
Overlapping Time: When filtering by time, you MUST check for events that overlap with the target time range (e.g.,
```
start1 < end2 AND start2 < end1
```
) to ensure you don't miss slices that span across the boundaries.

先看指标： 在深入自定义SQL之前，先使用追踪指标获取全局视图（例如：
```
./trace_processor --run-metrics android_startup
```
）。
从宽到窄： 从使用最少过滤条件的宽泛查询开始。优先使用模糊匹配（例如：
```
GLOB '*abc*'
```
）而非精确匹配。
时间重叠： 按时间过滤时，必须检查与目标时间范围重叠的事件（例如：
```
start1 < end2 AND start2 < end1
```
），确保不会遗漏跨越时间边界的切片。

3. Analyze and Drill Down (Depth-First)

3. 分析并深入挖掘（深度优先）

Evidentiary Rigor: Do not draw conclusions without explicit data.
Wall Time vs. CPU Time: Do not assume a long-running slice is actively computing. You MUST query the
```
thread_state
```
table for the exact timestamp window of suspicious slices to verify if the thread was
```
Running
```
,
```
Runnable
```
(waiting for CPU), or
```
Sleeping
```
/
```
Uninterruptible Sleep
```
(blocked).
Follow Dependencies: If a thread is blocked/waiting, you MUST find what it is waiting for (Binder, Lock, I/O, etc.). Cross process boundaries if necessary. You cannot conclude an investigation on a waiting thread without identifying the blocker.

证据严谨性： 若无明确数据，请勿得出结论。
挂钟时间 vs CPU时间： 请勿假设长时间运行的切片一直在进行计算。必须查询
```
thread_state
```
表，获取可疑切片的确切时间窗口，以验证线程处于
```
Running
```
、
```
Runnable
```
（等待CPU）还是
```
Sleeping
```
/
```
Uninterruptible Sleep
```
（阻塞）状态。
追踪依赖关系： 如果线程处于阻塞/等待状态，必须找出它在等待什么（Binder、锁、I/O等）。必要时跨进程追踪。若未识别出阻塞源，则不能结束对等待线程的调查。

4. Exhaustive Investigation (Do Not Give Up Early)

4. 全面调查（请勿过早放弃）

Multiple Bottlenecks: Complex performance issues rarely have a single cause. Do NOT stop your investigation after finding the first anomaly. Even if you find a major bottleneck (e.g., emulator graphics lag), you MUST continue searching for other independent system-wide issues (e.g., lock contention, I/O stalls). To find other bottlenecks, search through the content of the "Domain Hints" files (
```
CPU
```
,
```
Graphics
```
,
```
I/O
```
,
```
IPC
```
,
```
Memory
```
,
```
Power
```
) to retrieve and leverage expert-vetted, powerful trace analysis techniques. Investigate each relevant hint with depth.
Global Verification: Periodically perform a system-wide query for the longest running slices (
```
ORDER BY slice.dur DESC
```
) and most frequent D-states to ensure your local investigation hasn't missed a massive, unrelated system stall.
Persist Through Dead Ends: If a hypothesis is disproven or a query returns empty, do not conclude. Pivot your focus, broaden your search constraints (fuzzy matching, wider time windows), and continue the mission.

多瓶颈问题： 复杂的性能问题很少只有单一原因。找到第一个异常后请勿停止调查。即使发现了主要瓶颈（例如：模拟器图形卡顿），仍必须继续寻找其他独立的系统级问题（例如：锁竞争、I/O停滞）。要找到其他瓶颈，请查阅“领域提示”文件（
```
CPU
```
、
```
Graphics
```
、
```
I/O
```
、
```
IPC
```
、
```
Memory
```
、
```
Power
```
）的内容，检索并利用经专家验证的高效追踪分析技术。深入调查每个相关提示。
全局验证： 定期执行系统级查询，找出运行时间最长的切片（
```
ORDER BY slice.dur DESC
```
）和最频繁的D状态，确保局部调查未遗漏重大的、无关的系统停滞问题。
突破死胡同： 如果假设被推翻或查询返回空结果，请勿结束调查。调整关注点，扩大搜索范围（模糊匹配、更宽的时间窗口），继续完成任务。

Final Report

最终报告

Only when you have followed the entire chain of dependencies to the root cause(s) AND confirmed through exhaustive search that no other major bottlenecks exist: 1. Summarize your findings detailing the verified chain of evidence. 2. Conclude with: "This concludes the trace analysis. You can review the full chain of evidence in [scratchpad_filename]. Let me know if you would like me to drill down into any of these specific threads, or if you'd like help drafting a bug report."

只有在完整追踪依赖关系找到根本原因并且通过全面搜索确认不存在其他主要瓶颈时：1. 总结调查结果，详细说明已验证的证据链。2. 结尾附上：“本次追踪分析结束。您可以查看[暂存文件名]中的完整证据链。如果您希望我深入分析这些特定线程，或需要帮助撰写Bug报告，请告知我。”