跳转至

终端启动计时

针对 #19333,在打开新终端之前,在其 DevTools 控制台中启用渲染器的可选启用记录器:

localStorage.setItem('orca:terminal-startup-timing', '1')

删除该键即可禁用它。现有会话不受影响。若要捕获现有宿主生成阶段,请使用 ORCA_PTY_SPAWN_TIMING=1 启动宿主。不要仅为了启用诊断而重启有活动工作的宿主。

渲染器通过现有本地诊断通道,为每个传输回调代次发出一个 terminal_startup_timing 面包屑。在 main.trace.ndjson 中,查找 breadcrumb.name 匹配的 renderer.breadcrumb 记录。宿主现有的控制台计时行也会成为一条 pty.spawn.timing 跟踪记录。关联可用的 PTY ID;渲染器代次用于区分重试。比较各进程内的经过时长,而不是跨宿主的墙钟时间。

渲染器偏移量是从传输操作前立即创建的回调代次起算的单调递增毫秒数:

Field Observation
connected 当前代次的传输连接回调已被接受
liveData 首个非空实时投递,包括仅控制输出
submitted 首个发送到渲染器输出调度器的实时批次
writeStarted 调度器调用该批次的写入前回调
parsed Xterm 调用该批次的完成回调
renderEvent 批次开始写入后的首个公开 xterm 渲染事件

渲染事件可能先于解析回调。这些观察结果不能确定首个可打印字形、物理屏幕呈现、React 挂载时间或点击到绘制延迟。重放和合成重置写入不会占用首个实时批次。重放或调整大小仍可能在实时写入后促成渲染事件,因此该事件是时间证据,而非对确切内容的归因。隐藏或恢复的面板可能永远不会提交实时批次;缺失的字段保持缺失。队列上限警告可以继承写入前回调,同时丢弃原始批次的解析回调。在这种情况下,writeStarted/renderEvent 描述的是不完整的写入前活动,而不是原始批次的成功投递;没有 parsed 就无法观察结果。

记录器在连接、解析和渲染观察之后结束,或在替换、处置、错误或十秒诊断截止期时结束。启用期间,它仅保留阶段编号和标识符,并带有一个计时器以及至多一个渲染监听器。它不保留终端文本、命令、凭据或转录缓冲区。禁用记录不会添加任何监听器或计时器。

宿主 phaseDurations 保留当前阶段边界:计时器在初始所有权查找之后启动,并在所有提交/序列化器工作完成之前记录。totalMs 是该测量区间,而不是完整 IPC 延迟。provider_spawn 包括 provider 调用及其周围协调;它不是原始进程创建时间。外层跟踪记录是一个诊断快照,而不是覆盖该区间的 span。

可靠性不变量:诊断不得更改终端输出、投递额度、provider 所有权或生成结果。故障来源:Windows OMP 首次绘制报告 #19333。验证标准:可选启用记录器测试区分已排队、已解析和渲染里程碑;现有实时投递和同步输出测试套件保留输出行为。不存在与启动诊断匹配的可靠性门禁;完整的点击到物理呈现仍是一个明确的验证缺口。原生、守护进程、WSL 和 SSH 执行仍由宿主拥有;这不会添加任何传输字段或远程进程查询。移动端没有记录器更改。macOS/Linux/Windows 渲染器计时使用相同的公开 xterm 事件;物理设备计时需要单独捕获。

本页原文 Markdown:在 AtomGit 查看·内容源自开源项目 orca48/orca