fix(performance): go-faster counts paged reads and re-reads of growing task output as repeats
维护者通常 1 天内回复
评估
- 难度
- 3/5
- 预计耗时
- 半天
- 新手友好度
- 72/100
- Issue 类型
- 缺陷
- 描述清晰度
- 描述清楚
- 活跃度
- 活跃
- 技术栈
- python
- 领域
- performance, tooling
调研方向
Start in plugins/performance/scripts/findings.py around the Read and Bash transcript-count keys (near lines 897-898). Key reads on (file_path, offset, limit) and skip or downgrade Bash reads of session background-task output (tasks/*.output) and commands whose target changed. Add a regression test covering paged reads of one file and re-reads of a growing task output that expects no measured now-repeat findings.
由索引模型根据 Issue 内容生成。
描述
Problem
/performance:go-faster's session-work area offers "Adopt now" batching findings for reads and commands that were not repeats.
findings.py transcript-counts keys a Read on file_path alone (plugins/performance/scripts/findings.py:897-898) and a Bash call on its command text. So:
- Paged reads of one large file (same path, different
offset/limit) count as the file "read 3 times". - Re-reading a background task's output file while the task is still writing to it counts as "the same command run 2 times", although its input changed between the two runs.
Both were offered as now items (session-work-2, session-work-3) with the advice "reuse the earlier output while its inputs are unchanged". Following it would have been wrong in both cases: the reused output would have been a different section of the file, or stale task output.
Evidence
Sweep run 20261004T190412Z, session 4c1577ca:
repeated_reads: a 109 KB handoff file read 3 times, at three different offsets, once each.repeated_commands:cat <background task output>run twice, minutes apart, while the task appended to the file.
Fix
- Key a Read on
(file_path, offset, limit), so only an identical read counts as a repeat. - Do not count a Bash read of a file the session's background tasks write to (
tasks/*.output), or a command whose target changed between runs, as a repeat. Where change cannot be detected, label the finding a candidate, not a measurednowitem. - Add a regression test with both shapes that expects no repeat finding.
- 主要语言
- Shell
- 星标
- 22
- 派生
- 2
- 平均合并
- 8 小时 34 分钟
- 30 天内合并 PR
- 946
环境准备
- 没有 Dockerfile 或 Docker Compose 文件
- 没有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
melodic-software/claude-code-plugins 的其他 Issue
-
needs-human needs-triage
难度 2/5 1-3 小时 新手友好度 82/100
melodic-software/claude-code-plugins#7636 · 1 条评论 ·
维护者通常 1 天内回复
-
agent-ready needs-human
难度 2/5 1-3 小时 新手友好度 77/100
melodic-software/claude-code-plugins#7598 · 4 条评论 ·
维护者通常 1 天内回复
-
good first issue priority: low
难度 2/5 1-3 小时 新手友好度 62/100
melodic-software/claude-code-plugins#7530 · 1 条评论 ·
维护者通常 1 天内回复
-
needs-human priority: medium
难度 2/5 1-3 小时 新手友好度 65/100
melodic-software/claude-code-plugins#7455 · 1 条评论 ·
维护者通常 1 天内回复
-
priority: medium
难度 2/5 1-3 小时 新手友好度 68/100
melodic-software/claude-code-plugins#7351 · 2 条评论 ·
维护者通常 1 天内回复
查看 melodic-software/claude-code-plugins 的全部 Issue
相似的 Issue
-
难度 1/5 1 小时以内 新手友好度 95/100
collabnix/awesome-mcp-lists#225 ·
维护者通常 9 天内回复
-
good first issue
难度 2/5 半天 新手友好度 88/100
-
documentation needs-triage priority:medium
难度 2/5 1-3 小时 新手友好度 85/100
yeongseon/azure-functions-validation-python#546 ·
维护者通常 1 天内回复
-
难度 1/5 1 小时以内 新手友好度 94/100
edoardottt/awesome-hacker-search-engines#371 ·
维护者通常 3 天内回复
-
bug cli libc sev-5
难度 2/5 1-3 小时 新手友好度 78/100