performance-tuning
Skill0 starsChanged 3 months agoMITView on GitHub
分析和优化程序性能。当遇到响应慢、CPU/内存/IO 占用高、吞吐低、延迟无法达标，需要先量化瓶颈再针对性优化，并验证优化收益与无回归时使用。
8 other projects use a version of this.
Adopted by
Most recently taken up by
- NoobyGains/godmodetheir own version, first seen Nov 1, 2026
- 0King0P/Claude-Skillstheir own version, first seen Oct 13, 2026
- devpilotX/skillstheir own version, first seen Sep 22, 2026
- jdanigo/hydraiatheir own version, first seen Sep 12, 2026
- SpencerGoss/agent-engineeringtheir own version, first seen Jun 18, 2026
- polardb/polardb-pg-skillstheir own version, first seen May 11, 2026
Other versions8 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 8
- NoobyGains/godmode★ 118same name
- jdanigo/hydraia★ 8same name
- polardb/polardb-pg-skills★ 2same name
- harrissohail6/claude-code-config★ 1same name
- 0King0P/Claude-Skills★ 0same name
- devpilotX/skills★ 0same name
- poteto0/my-skills★ 0same name
- SpencerGoss/agent-engineering★ 0same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository5 other files it gives its agents.
- code-reviewSkill
- debuggingSkill
- documentationSkill
- git-workflowSkill
- unit-testingSkill
The file
Files
性能优化
核心原则：先测量，再优化，后验证。没量化的优化大多是猜测。
使用步骤
1. 明确目标与基线（Target & Baseline）
- 目标是什么？(P95 延迟 < 200ms / 吞吐 ≥ 1000 QPS / 内存有界 / 启动 < 3s)
- 先测优化前的值作为基线，否则无法判断收益。
2. 量化，找瓶颈（Profile first）
用 profiler/计时，不要靠感觉：
- CPU：CPU profiler 找热点函数、火焰图。
- 耗时：打点计时，找最耗时的调用/阶段。
- 内存：heap profile，找对象/驻留增长。
- I/O / 网络：是否有阻塞、重试、串行等待、小包频繁传输。
- 数据库/存储：慢查询、缺少索引、N+1 查询、全表扫描。
按「最耗时 → 影响最大」排优先级，遵循二八原则：20% 的代码占 80% 的耗时。
3. 分析瓶颈性质
先判断是哪种，再决定对策：
- 算法复杂度问题：O(n²)/O(2ⁿ) 换成更低复杂度；缓存重复计算。
- 重复/浪费：重复请求、重复转换、重复解析、未复用连接/对象。
- I/O 瓶颈：批量代替逐条、异步非阻塞、连接池、减少往返。
- 并发/锁：锁竞争、串行化、死锁；用读写锁/无锁结构。
- 资源滥用：内存泄漏、缓存失效风暴、未关闭的文件/连接。
4. 尝试最小改动并立刻测量
- 一次只做一个优化，改完重新测量。
- 用相同压测基准对比前后，确保对比有意义。
5. 验证与回归
- 优化后达标且收益可量化（给出前后数字）。
- 功能/正确性无回归（跑测试）。
- 没引入新的资源问题（内存、句柄）。
- 代码复杂度/可读性没被优化破坏（必要时注释说明“为何这样写”）。
常见优化手段速查
| 瓶颈 | 手段 |
| 热点计算 | 降复杂度、记忆化/缓存、批量处理 |
| 网络往返 | 合并/批量请求、复用连接、异步 |
| 循环内 I/O | 移出循环、批量读写 |
| 数据库慢 | 加索引、避免 N+1、分页、缓存热点 |
| 内存增长 | 找泄漏、降驻留、对象复用 |
| 锁竞争 | 缩小临界区、读写分离、无锁替代 |
输出模板
目标：...
基线（优化前）：...
瓶颈定位（profiler/数据）：...
优化措施：...
结果（优化后，前后对比）：...
回归验证：...Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
Reviews can't be read right now.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.