Skip to content

perf: reduce multi-diagram generation latency without weakening quality gates - #208

Open
sunsunsun-java wants to merge 12 commits into
tt-a1i:mainfrom
sunsunsun-java:codex/issue-175-pipeline-performance
Open

perf: reduce multi-diagram generation latency without weakening quality gates#208
sunsunsun-java wants to merge 12 commits into
tt-a1i:mainfrom
sunsunsun-java:codex/issue-175-pipeline-performance

Conversation

@sunsunsun-java

Copy link
Copy Markdown
Collaborator

Problem and value

Repository-backed multi-diagram generation repeatedly loaded authoring contracts, schemas, examples, and repository evidence, then started separate validation/browser processes for each diagram. That made five-diagram runs unnecessarily slow and also encouraged repair loops that could drift in language, semantics, routing, or visual quality.

This change reduces avoidable orchestration and validation overhead while keeping the quality gates fail-closed. It also records stage-level timings so future regressions can be located instead of inferred from total wall time.

Closes #175.

Scope

  • What changed:
    • Added a compact, digest-pinned authoring context and project evidence index so one run can reuse repository facts without silently accepting stale inputs.
    • Added candidate preflight, authored-language checks, structured exact diagnostics, bounded repair plans, and repair receipts.
    • Added suite orchestration, shared-browser batch validation, run recording, timing reports, and matched A/B benchmark contracts.
    • Added reusable layout reports and viewBox-containment checks across architecture, sequence, data-flow, lifecycle, and workflow renderers.
    • Hardened endpoint routing and marker clearance, including data-flow bottom-to-bottom return edges, vertical arrow endpoints, lifecycle semantic arrows, and workflow v2 painted paths.
    • Preserved the upstream workflow v2 compiler and migration behavior while integrating the new quality and timing pipeline.
    • Regenerated checked-in examples, gallery output, release artifacts, and package smoke expectations.
  • What deliberately did not change:
    • No quality gate was removed or downgraded.
    • No typography shrinking, clipping, overflow hiding, semantic deletion, or model-specific bypass was introduced to make runs appear faster.
    • Workflow v1 fixed-layout output remains byte-compatible; new compiler behavior stays behind workflow schema v2.
  • No unrelated changes:
    • Local benchmark/run artifacts and the share-only summary draft are intentionally untracked and excluded from this PR.

Stability impact

  • Compatibility: existing workflow v1 fixed-layout documents retain their established rendering contract; workflow v2 documents use the upstream constraint-driven compiler and migration path.
  • Failure behavior: generation fails closed when contract digests, evidence, authored language, schema, geometry, containment, or exact visual diagnostics do not satisfy the contract.
  • Recovery/rollback: the previous deliverable is retained until the candidate passes its required gates; the four issue-scoped commits can be reverted independently if needed.
  • Operational visibility: each run now emits structured stage timing and repair information suitable for regression comparison.

Tests run

  • npm test from archify/: 1,218 tests; 1,191 passed; 0 failed; 27 skipped.
  • Validator generation, example/gallery/readme/delta regeneration, release identity, package smoke, and archive generation are covered by the full suite and all passed.
  • Focused authoring, project-index, repair-plan, routing, layout-report, workflow compiler, run-suite, visual CLI, and release-package tests passed before the full run.

Visual evidence

  • Headless visual-check batch: architecture and workflow standard examples passed.
  • Sequence, data-flow, and lifecycle standard tall examples still report viewer/viewport-overflow; they are explicitly not claimed as passing, and this PR does not suppress or hide that diagnostic.
  • Checked-in example/gallery HTML and the live-proof GIF/receipt were regenerated from the merged code.

Generated artifacts

  • archify.zip
  • renderer examples under archify/examples/ and examples/
  • gallery HTML, manifest, sources, and artifacts under docs/gallery/
  • docs/assets/archify-live-proof.gif and its JSON receipt
  • checkout delta HTML and receipt

Checklist

  • Issue-scoped implementation is committed on a dedicated branch.
  • Full repository test suite passes.
  • Generated validators and release artifacts are current.
  • Quality gates remain fail-closed.
  • Local benchmark artifacts and share-only notes are excluded.
  • Known visual-check non-passes are disclosed rather than bypassed.

@tt-a1i tt-a1i left a comment

Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reviewed at exact head 40fca32. The overall direction is valuable, and CI, package freshness, and the full local test suite are green, but the three correctness/performance issues below break the new fail-closed contracts and should be fixed before merge.

The performance acceptance evidence is also not complete yet: issue #175 starts from 2637.592s aggregate work, while the supplied 6e2f1d1-era run reports 2689.103s and includes uncommitted fixes. Those numbers are not a matched A/B comparison and do not bind the current head. Please attach current-head matched A/B receipts for the same pinned Pi revision, runtime, prompts, semantic coverage, and visual gates before claiming the 20-30% reduction.

id: 'repository-revision',
kind: 'repository-revision',
executable: 'git',
args: ['-C', repoRoot, 'rev-parse', 'HEAD'],

Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[P1] Bind suite execution to a clean pinned checkout

This gate checks only git rev-parse HEAD, while manifest exec commands may run with cwd: repository. A checkout with modified tracked files or untracked files therefore passes, and a generator can consume those bytes while the final receipt still attributes the run to the clean commit SHA. That breaks the documented revision-pinned and fail-closed contract. Please reject dirty worktrees before creating output and re-check after generator commands or before the final receipt, with regression coverage for both tracked and untracked drift.

});
}
}
const matches = found.slice(0, query.maxResults);

Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[P1] Make maxResults bound the source-search work

maxResults is applied only after all selected blobs have been loaded and every matching line has been materialized. On this exact head, source-search --term function --max-results 1 against this repository scanned 517 files, accumulated 38,522 matches, returned one result, and took about 19.8 seconds. This recreates the repeated repository-scan cost that #175 is intended to remove. Please bound the files and total bytes and stream or stop once the requested result budget is reached, or require an explicit narrow path filter, instead of building the complete found array.

Comment thread archify/bin/archify.mjs Outdated
const titleMatches = requiredLanguage === 'zh-CN' ? hasCjk : hasLatin && !hasCjk;
const technicalIdentifiers = entries.filter((entry) => isTechnicalAuthoredText(entry.text));
const proseEntries = entries.filter((entry) => !isTechnicalAuthoredText(entry.text));
const proseViolations = requiredLanguage === 'zh-CN'

Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[P1] Enforce both language directions without rejecting product names

For en, this branch always makes proseViolations empty. A candidate with meta.locale: en, an English title, and Chinese reader-facing body labels returns success with violations: 0. Conversely, isTechnicalAuthoredText rejects any string containing whitespace, so a Chinese candidate rejects an exact product name such as GitHub Actions, despite the contract requiring product and code identifiers to be preserved. Please add symmetric reader-facing validation plus bounded identifier/product-name handling, with regression tests for both cases.

@sunsunsun-java

Copy link
Copy Markdown
Collaborator Author

@tt-a1i Thank you for the detailed review. I have pushed the new head 1195611. It addresses the three P1 findings: clean revision-pinned checkout enforcement, source search that stops materializing blobs once maxResults is proven truncated, and symmetric authored-language validation while preserving bounded product and technical names. It also adds the workflow main-path lane reflow guard and regression coverage for repeated lane re-entry. Local verification on this exact head passed: 1,258 tests with 0 failures and 27 expected skips; deterministic archify.zip byte comparison passed; packaged-skill smoke passed. GitHub CI for this exact head has started and is currently queued. I am not treating the existing local A/B artifacts as exact-head acceptance evidence, and I will not claim the 20–30% target until a matched current-head receipt is attached. Could you please re-review the correctness fixes after CI completes?

@sunsunsun-java
sunsunsun-java requested a review from tt-a1i August 30, 2026 15:02

Copy link
Copy Markdown
Collaborator

PR #208 完整基准:多模型、多强度、多代码库五图生成

测试时间:2026-08-30 至 2026-08-31(Asia/Shanghai)
测试对象:固定 PR 提交 1195611
基线:PR 前提交 7fe139e
目标:验证多图流水线是否真正变快,以及性能优化是否造成语义或视觉质量下降。

Important

发布这份报告时,PR 已前进到新 head c8fc9f5。以下数字是对 1195611 的固定提交证据,不能冒充 c8fc9f5 的 exact-head 验收;当前 head 仍应重新执行同口径 matched A/B。

先给结论

问题 结论 证据
PR 的机械流水线是否变快? 固定同一批候选的 3 轮 ABBA:36.457s → 25.859s,配对中位耗时 -29.5%,配对 P95 -25.5%
真实端到端是否稳定变快? 暂时不能确认 Sol-high 严格串行 A 为 30:29.998;B 的创作到 suite 观察墙钟为 38:35.149,本次反而长 26.5%,但 B 运行时存在多 session 竞争,不能做因果归因
图的质量是否下降? 没有发现下降 同一审阅者盲审:A 语义/视觉 98.8/78.8,B 为 100.0/92.8;两套均无硬失败,B 视觉高 14 分
五图能否完整交付? Pi + Sol-high 可以,其他组合不稳定 Pi/Sol-high 5/5;FastAPI/Terra-high 0/5;uv/Terra-xhigh 1/5
弱模型或低强度一定更快吗? 不是 GPT-5.5 2:21 完成;Qwen 3.8 27B 在 35:15 上限内仍未完成首图;Luna-low 自动通过后仍有语义硬缺项
flowchart LR
  A["A:PR 前串行流水线<br/>36.457 秒"]
  B["B:PR #208 批处理流水线<br/>25.859 秒"]
  A -->|"配对中位 -29.5%"| B
  QA["A 盲审<br/>语义 98.8 / 视觉 78.8"]
  QB["B 盲审<br/>语义 100.0 / 视觉 92.8"]
  QA -->|"没有质量下降<br/>视觉 +14.0"| QB
Loading
xychart-beta
  title "固定候选流水线墙钟(越低越好)"
  x-axis ["A 串行", "B PR #208"]
  y-axis "秒" 0 --> 40
  bar [36.457, 25.859]
Loading

1. 测试设计与版本固定

对象 固定版本
PR #208 B 1195611f84cf02b78c30278ce71b12c5795b7ea1
PR 前 A 7fe139ebe2e532941eb4c315057294348e88a2c0
Pi e86823096c5bad39e1ca282ec24bc5eb9bec745b
FastAPI 49033471594ea5d99a80abdf1043231b7791ee49
uv 7896d580c245493c88ea5be56724e6e42ee7d197

为避免把“模型差异”误算成“PR 性能”,测试分成两层:

  1. 严格机器 ABBA:候选图、语义合同、repo revision、运行时和质量门禁全部固定,只切换 A/B 流水线。这一层用于判断 PR 自身的性能变化。
  2. 真实 Agent 端到端:让不同模型从源码证据开始创作、修复、验证、交付和视觉检查。这一层用于观察真实使用体验,但会受到模型策略、修复轮数和并发资源竞争影响。

Pi 合同固定:

  • 37 条源码事实;
  • 47 个必要节点;
  • 68 条关系或时序消息;
  • 五种图共 20 个引导视图;
  • 90 分语义通过线及硬失败条件;
  • 截断的 toolCall 不执行;
  • 工具根据 executionMode 顺序或并行;
  • steering 与 follow-up 的注入时机不同;
  • agent_end 先于 listener settlement / finishRun / idle;
  • transcript 是内存状态,不得虚构数据库或固定模型厂商。

测试环境验证:

  • PR 焦点测试:161/161 通过;
  • 全量 npm test:1,258 项,1,227 通过,31 项为明确环境门控跳过,0 失败;
  • 候选、基线、Pi、FastAPI、uv 固定 checkout 均为 clean;
  • 所有 suite 都绑定 repo-root 和 revision,预检失败时 fail-closed,不伪造 deliver/visual 成功。

2. 严格机器 ABBA:PR 自身是否加速

测试采用 warmup=1、rounds=3、ABBA 顺序,共获得每臂 6 个正式样本。

指标 A:PR 前串行 B:PR #208 批处理 变化
中位墙钟 36,457.138 ms 25,858.507 ms -10,744.190 ms / -29.5%
P95 37,706.133 ms 27,150.590 ms 配对 P95 -25.5%
facts 37/37 37/37 相同
nodes 47/47 47/47 相同
relations/messages 68/68 68/68 相同
views 20/20 20/20 相同
质量合同 PASS PASS 没有降级

因此可以确认:共享项目索引、共享预检、批量 suite 和共享视觉批次确实减少了机械重复开销,同时没有删除事实、节点、关系、view 或视觉步骤。

需要特别区分:Issue #175 中的 2,637.592s 是 aggregate agent work,不是并发墙钟。它与本次 B 的 38:35.149 不是同口径,不能用二者直接宣称 12.2% 端到端加速。


3. Pi 五种图:完整交付与每图耗时

Pi + Sol-high 在 PR B 上完成并交付 5/5:

图类型 自动验证轮数 并发创作包络 候选冻结后的独占处理 自动门禁 语义人审 视觉人审
架构图 10 33:19.324 764 ms 9/9,通过 94 84
工作流图 19 33:19.228 881 ms 9/9,通过 96 88
时序图 5 33:19.201 624 ms 9/9,通过 97 88
数据流图 9 33:19.075 567 ms 9/9,通过 95 90
生命周期图 10 33:18.947 613 ms 9/9,通过 94 86

五个约 33:19 的创作包络是同时启动、互相重叠的,不能相加。候选冻结后,五图原生 suite 总墙钟为 29.715 秒;共享视觉批次另计 16.381 秒。

基线 A 的严格串行 20 阶段耗时:

图类型 Authoring Validation/repair Delivery Visual 合计
架构图 84.159s 101.945s 10.347s 57.136s 4:13.587
工作流图 70.804s 268.579s 9.238s 54.623s 6:43.244
时序图 47.905s 11.666s 11.265s 166.047s 3:56.883
数据流图 58.216s 229.733s 0.152s 63.622s 5:51.723
生命周期图 70.556s 319.418s 0.148s 194.375s 9:44.497
总计 30:29.998

独立 A/B 十图盲审:

版本 语义均分 视觉均分 硬失败
A 98.8 78.8 0
B 100.0 92.8 0
B - A +1.2 +14.0 0

B 的 workflow、dataflow、lifecycle 对画布利用明显更充分;A 的 workflow/dataflow 虽通过自动门禁,但在 1440×900 下主图偏小。这也是为什么自动几何检查必须配合实际渲染与独立人审。


4. Codex 多 Session、模型与推理强度

本次使用并行 session/agents 分离源码合同、基线 A、OpenRouter 盲审和 Sol A/B 盲审,并对 Luna、Terra、Sol 的不同强度进行测试。

模型配置 任务结果 质量证据 判断
gpt-5.6-sol / high,B Pi 5/5 通过并交付;观察墙钟 38:35.149 根审语义 95.2、视觉 87.2;盲审 100/92.8 最可靠的完整五图结果
gpt-5.6-sol / high,A Pi 5/5;严格墙钟 30:29.998 37/37 facts、20/20 views;盲审 98.8/78.8 本次端到端快于 B,但计时路径和负载不完全配对
gpt-5.6-luna / low,B 架构自动通过;工作流在约 557s 内失败,未完成五图 架构盲审 72/68,缺少“事件与状态”必需 view,构成硬失败 自动门禁通过不等于语义完整
gpt-5.6-terra / high,B 9:16.800 内五图共享预检 0/5 候选保留部分合同语义,但布局门禁失败 正确 fail-closed,无交付
gpt-5.6-terra / high,A 架构多轮修复后仍有 24 个几何错误 未交付 老串行路径同样受候选质量制约
gpt-5.6-terra / xhigh,B(随机抽签) 37:00.564 内仅架构 1/5 通过 其余存在路由、可读性或语言门禁失败 更高强度不保证更快或更稳定

结论:模型创作/修复时间远大于候选冻结后的流水线时间。 PR 优化解决了机械重复工作,但无法自动消除弱候选、修复循环和模型工具调用效率差异。


5. OpenRouter 常见模型同题测试

所有运行均使用同一个固定 Pi revision、同一架构图合同、同一 PR B CLI,并要求最多 12 轮修复。只向模型提供公开 Pi 源码证据;没有发送私有代码库或凭据。

pie showData
  title OpenRouter 八组运行交付结果
  "完成自动门禁、交付与视觉检查" : 5
  "限定窗口内未完整交付" : 3
Loading
模型 端到端墙钟 自动结构合同 独立语义/视觉 自动门禁/交付/视觉 费用
GPT-5.5 2:21.776 48.5/50 98/91 通过 $1.130659
Claude Sonnet 4.6 3:32.802 39.5/50 89/92,语义差 1 分未过线 自动通过 $0.719916
Gemini 3.7 Flash 3:48.407 50/50 97/86 通过 $0.221396
Seed 2.1 Turbo 6:45.797 45.5/50 98/92 通过 $0.103885
Kimi K2.7 Code 8:23.971,越过 12 轮后中止 50/50,但未过最终门禁 未评,未完整交付 未通过 $1.101174
GLM 5.3 8:25.479 50/50 91/84 通过 $0.813816
DeepSeek V3.2 14:21.522 47/50,未过最终门禁 未评,未完整交付 未通过 $0.470678
Qwen 3.8 27B 35:15.911,上限停止 47/50,未过最终门禁 未评,未完整交付 未通过 $1.297355

八组实测合计费用 $5.858879,5/8 完成交付。

观察:

  • 最快完整结果:GPT-5.5,2:21.776,语义/视觉 98/91。
  • 成本/质量比最佳:Seed 2.1 Turbo,$0.103885,语义/视觉 98/92。
  • Gemini 快且语义完整,但视觉 86,低于 Seed/GPT/Claude。
  • Claude 的自动门禁和视觉检查都通过,独立语义盲审却只有 89;说明自动结构合同不能替代源码时序语义复核。
  • Kimi 的结构合同达到 50/50,但模型无视 12 轮修复上限;在第 14 份失败收据后被中止,不能把“结构分满分”冒充“完整交付”。
  • Qwen、DeepSeek、Kimi 的失败均作为 bounded-stop 保留,没有用部分产物冒充五图成功。

6. 跨代码库五图测试

代码库 / 模型 五份候选 共享预检 原生 suite 交付 主要问题
Pi / Sol-high 5 5/5 29.715s,通过 五份 HTML + 视觉证据 少量文字偏小、路径密集
FastAPI dependencies / Terra-high 5 0/5 1.701s,fail-closed 标签路径净空、节点重叠、桌面可读性
uv resolver / Terra-xhigh 5 1/5 7.234s,fail-closed 节点内路由、标签宽度、路径穿越、状态重叠

FastAPI 与 uv 并不是“没跑”:两者都固定源码证据、生成五份候选、绑定正确 repo-root/revision,并真实执行 run-suite --concurrency 5。共享预检失败后没有继续 deliver/visual,说明 fail-closed 质量合同生效。

flowchart TD
  S["固定源码证据与 revision"] --> C["并发生成五种候选"]
  C --> P{"共享预检"}
  P -->|"Pi 5/5"| D["Deliver + shared visual batch"]
  P -->|"FastAPI 0/5"| F1["Fail closed<br/>不生成伪成功"]
  P -->|"uv 1/5"| F2["Fail closed<br/>保留失败收据"]
Loading

7. 如何理解“更快”和“质量是否降低”

可以确认

  • 冻结候选后的批处理、共享项目索引、共享预检和共享视觉批次,配对中位耗时下降 29.5%
  • 严格 ABBA 的 A/B 使用完全相同的候选和合同,B 没有删除质量步骤。
  • 独立创作的 Sol A/B 盲审中,B 不仅没有变差,语义高 1.2、视觉高 14.0。

不能确认

当前主要瓶颈

  1. 模型读取源码后首次候选的质量;
  2. 路由、标签净空、节点重叠等布局修复轮数;
  3. 模型是否遵守修复轮数和终止条件;
  4. 多 session 同机运行时的 CPU、浏览器和进程竞争。

换句话说:PR #208 已经实质缩短“流水线机械部分”,但真实五图任务绝大多数时间仍花在 authoring 和 repair。 下一步性能工作应该把 Agent authoring receipt 标准化,并在相同模型、相同负载、相同提示、相同机器条件下做端到端 ABBA。


复现实验建议与验收口径
  1. 固定 PR/base SHA、被分析代码库 SHA、Node/Chrome 版本和所有提示合同。
  2. 每臂先 warmup,再采用 ABBA/BAAB 交错顺序,避免热缓存和机器负载单向偏置。
  3. 每次运行保存 stage timing、repair receipts、contract digest、repo cleanliness 和最终 artifact hash。
  4. 将耗时拆成 authoring、validation/repair、delivery、visual;不要只记录总时间。
  5. 质量至少同时报告:源码事实、节点、关系/消息、view、禁词、几何门禁、实际渲染、人审。
  6. 未通过 preflight 的候选必须 fail-closed;不能补写假的 HTML/截图或人工改状态为成功。
  7. aggregate agent work、单进程墙钟、并发 session 包络、冻结候选 suite 时间必须分栏呈现,禁止混用。
局限
  • 严格 ABBA 固定候选,因此隔离了 pipeline 差异,但不包含模型创作时间。
  • Sol A 使用严格串行 receipt;Sol B 是较早开始的 pre-profile 观察值,且当时有其他 session 争用,二者不是同负载随机配对。
  • OpenRouter 只覆盖八个代表性模型家族,不代表完整目录。
  • 人审分是固定合同下的源码语义与视觉评估,不等于最终用户验收。
  • FastAPI/uv 结果表明当前 authoring 的跨代码库泛化仍不足,不能只用 Pi 5/5 推断所有仓库都可稳定交付。

最终判断

在固定提交 1195611 上,PR #208 的核心性能方向成立:严格同候选的可归因测试中,机械流水线快约 29.5%,质量门禁没有被削弱。

但目前最准确的表述应是:

固定提交 1195611 显著降低了多图验证与交付阶段的重复开销;真实 Agent 端到端收益尚未稳定,因为模型创作和修复仍占绝大多数时间。现有 Pi/Sol-high 结果未发现质量下降,反而显示更好的视觉质量;弱模型和跨代码库测试则暴露了 authoring 泛化与自动语义门禁的边界。当前 c8fc9f5 需重新跑 exact-head matched A/B 后才能继承这一性能结论。

这比“整体已经稳定快 20–30%”更符合当前证据。

@tt-a1i tt-a1i left a comment

Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reviewed current head c8fc9f5. The earlier dirty-worktree/read-bound regressions have focused fixes and passing tests. One language-gate compatibility issue still reproduces.

[P2] Allow valid single-character Chinese branch labels and preserved product names (archify/authoring/authored-language.mjs:95-107). Starting with a valid workflow fixture, validate --required-language zh-CN succeeds. Changing only two edge labels to 是 and 否 makes it fail in the language phase; changing only a node label to Google Cloud likewise fails. The former are ordinary Chinese branch labels, and the latter is an original proper product name that SKILL.md:93-94 and authoring-contract.md explicitly allow preserving. The chineseCount < 2 rule and narrow name heuristic reject legitimate authoring rather than language leakage. Cover both cases through the public CLI and preserve real mixed-language detection.

Verification:627 tests passed,0failed,5canonical ZIP checks skipped under Node24; golden passed and all28 checked generated-receipt relationships match,91ZIPpayload files match. Additional CLI control/negative fixture confirms this finding despite that green suite. No claim of matched end-to-end performance improvement or manual visual acceptance from these checks. No edits or merge.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

perf: reduce multi-diagram generation latency without weakening quality gates

3 participants