comm: per-line get_flag lookups and allocation in the main loop
维护者通常 1 天内回复
还没有人认领这个 Issue。
评估
- 难度
- 2/5
- 预计耗时
- 1-3 小时
- 新手友好度
- 78/100
- Issue 类型
- 重构
- 描述清晰度
- 描述清楚
- 活跃度
- 活跃
- 技术栈
- rust
- 领域
- cli, performance
调研方向
从 src/uu/comm/src/comm.rs 开始，重点查看第 227、242 和 258 行附近的主循环，以及第 134、139 和 153 行附近的 OrderChecker::verify_order。分别在带有和不带 --nocheck-order 的情况下运行提供的 seq 和 comm 基准测试，然后运行现有测试。当查找次数和每行分配都减少，同时输出保持逐字节一致且性能得到提升时，即可视为完成。
由索引模型根据 Issue 内容生成。
描述
In comm, the main loop calls opts.get_flag(options::COLUMN_1/2/3) on every line (lines 227, 242 and 258 of src/uu/comm/src/comm.rs) which is a clap lookup by string.
OrderChecker::verify_order also does self.last_line = current_line.to_vec() on every line (lines 134, 139 and 153), so each line allocates.
Setup: Debian 13, aarch64 (Docker VM), LC_ALL=C, release build of main at 070d78da1 (LTO off), GNU coreutils 9.7.
How to reproduce:
seq -f 'k%08.0f' 1 2 2000000 > ca
seq -f 'k%08.0f' 1 3 3000000 > cb
LC_ALL=C comm -123 ca cb
Time, median of 9 runs:
| GNU 9.7 | main | patched | |
|---|---|---|---|
comm ca cb > file |
101 ms | 197 ms | 117 ms |
comm -123 ca cb |
67 ms | 159 ms | 85 ms |
comm --nocheck-order -123 ca cb |
60 ms | 99 ms | 67 ms |
With --nocheck-order the order checker never runs so only the flag lookups differ. The number of write calls is identical before & after, so the output side is not the cause.
My patch hoists the three flags out of the loop and reuses the buffer (clear() + extend_from_slice). It's 25 lines, byte-identical to GNU's output and the existing tests pass.
For transparency, I noticed this issue thanks to an LLM.
- 主要语言
- Rust
- 星标
- 24.3k
- 派生
- 2.1k
- 平均合并
- 1 天 16 小时
- 30 天内合并 PR
- 310
环境准备
在浏览器里用你自己的 GitHub 账号启动这个项目的开发容器。
- 没有 Dockerfile 或 Docker Compose 文件
- 没有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
uutils/coreutils 的其他 Issue
-
minorbug(mv): invalid mode errors not quoted可能已有人在做 @henrimarconni 于 1 天前认领。 未关闭U - mv
难度 2/5 1-3 小时 新手友好度 72/100
维护者通常 1 天内回复
-
ptx: break file missing path in error message可能已有人在做 @Franklin-Qi 于 1 天前认领。 未关闭U - ptx
难度 2/5 1-3 小时 新手友好度 82/100
uutils/coreutils#15307 · 1 条评论 ·
维护者通常 1 天内回复
-
minorbug(stat): os errno not stripped when failing to flush stdout可能已有人在做 @cestercian 于 8 天前认领。 未关闭U - stat
难度 2/5 1-3 小时 新手友好度 67/100
uutils/coreutils#15200 · 3 条评论 ·
维护者通常 1 天内回复
-
stty: support B460800 and B921600 baud rates可能已有人在做 @oech3 于 4 天前认领。 未关闭awaiting upstream U - stty
难度 2/5 1-3 小时 新手友好度 72/100
维护者通常 1 天内回复
-
B - high priority U - du
难度 1/5 1 小时以内 新手友好度 82/100
uutils/coreutils#14984 · 1 条评论 ·
维护者通常 1 天内回复
相似的 Issue
-
难度 2/5 1-3 小时 新手友好度 82/100
维护者通常 1 天内回复
-
难度 1/5 1 小时以内 新手友好度 88/100
pop-os/cosmic-comp#2956 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 78/100
维护者通常 1 天内回复
-
area:release criticality:p3 documentation
难度 2/5 1-3 小时 新手友好度 68/100
registrystack/registry-stack#2085 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 85/100
libp2p/rust-libp2p#6694 ·
维护者通常 1 天内回复