optimization
Compare original and translation side by side
🇺🇸
Original
English🇨🇳
Translation
ChineseOptimization
优化
Use this skill when the task is about making a system faster, lighter, more scalable, or otherwise more efficient.
当任务是让系统更快、更轻量化、更具扩展性或在其他方面更高效时,使用此技能。
Core principle
核心原则
To optimize properly, you must know:
- What metrics you are chasing
- What your real bottlenecks are
Do not optimize blindly.
要进行合理优化,你必须明确:
- 你追求的具体指标
- 真正的瓶颈所在
不要盲目优化。
1. Define the target metrics first
1. 先定义目标指标
Before changing code, make sure you have the right measurements.
- Identify the exact metrics that matter: latency, throughput, memory, CPU, startup time, compile time, query count, token usage, cost, etc.
- Measure comprehensively, not just a convenient subset.
- Make sure the metrics are accurate and representative of the real workload.
- Prefer measurements that are fast to run so you can iterate quickly.
- If possible, create repeatable benchmarks or scripts so improvements are verifiable.
在修改代码之前,确保你有合适的测量方式。
- 确定关键的具体指标:延迟、吞吐量、内存、CPU、启动时间、编译时间、查询次数、token使用量、成本等。
- 进行全面测量,而不仅仅是方便获取的子集。
- 确保指标准确且能代表真实工作负载。
- 优先选择运行速度快的测量方式,以便快速迭代。
- 如有可能,创建可重复的基准测试或脚本,以便验证优化效果。
2. Get full bottleneck attribution
2. 全面定位瓶颈
You should have strong attribution for what each part of the system is doing.
- Instrument the system so you can see where time and resources are going.
- Prefer both:
- Ad hoc inspection for quick debugging
- Logged measurements for later analysis and comparison
- Attribute work across the full path, not just the obviously slow component.
- Make sure the data is detailed enough to explain where the cost comes from.
If you can analyze runs after the fact with logs or traces, that is often much more powerful than relying only on live inspection.
你应该能够明确系统各部分的资源消耗情况。
- 为系统添加监控,以便查看时间和资源的去向。
- 优先同时使用:
- 临时检查用于快速调试
- 日志测量用于后续分析和对比
- 追踪整个流程的资源消耗,而不仅仅是明显缓慢的组件。
- 确保数据足够详细,能解释成本来源。
如果能通过日志或追踪事后分析运行情况,通常比仅依赖实时检查更有效。
3. Use static analysis too
3. 同时使用静态分析(static analysis)
Not every optimization problem needs runtime profiling first. Often, code inspection reveals the issue.
Check for:
- Wrong asymptotic complexity
- The wrong algorithm or data structure
- Unnecessary repeated work
- Work happening in the wrong layer
- Inefficient architecture or control flow
- Directionally incorrect approaches
Make sure your asymptotics are right and the overall algorithm makes sense before tuning small details.
并非所有优化问题都需要先进行运行时分析。代码检查往往就能发现问题。
检查以下内容:
- 错误的渐近复杂度
- 错误的算法或数据结构
- 不必要的重复操作
- 操作发生在错误的层级
- 低效的架构或控制流
- 方向错误的解决方案
在调整细节之前,确保渐近复杂度正确且整体算法合理。
4. Macro-optimize before micro-optimizing
4. 先进行宏观优化,再进行微观优化
Prioritize the largest wins first.
- Remove whole classes of work before making existing work slightly cheaper.
- Fix architecture, batching, caching, query patterns, algorithm choice, parallelism, and data movement before focusing on tiny low-level tweaks.
- If you are very far from the expected metrics, spend more time on macro-optimization.
Micro-optimizations matter most after the major inefficiencies are already addressed.
优先选择收益最大的优化方式。
- 在降低现有操作的成本之前,先消除整类不必要的操作。
- 在关注微小的底层调整之前,先修复架构、批处理、缓存、查询模式、算法选择、并行性和数据移动等问题。
- 如果当前指标与预期差距较大,应投入更多时间进行宏观优化。
只有在解决了主要低效问题后,微观优化才最为重要。
Recommended workflow
推荐工作流程
- Define success metrics.
- Reproduce the current baseline.
- Add measurement and attribution if missing.
- Identify the top bottleneck.
- Check for algorithmic or architectural issues.
- Apply the highest-leverage fix first.
- Re-measure.
- Repeat until the target is met or tradeoffs stop being worth it.
- 定义成功指标。
- 重现当前基准线。
- 补充缺失的测量和定位手段。
- 确定首要瓶颈。
- 检查算法或架构问题。
- 首先应用收益最高的修复方案。
- 重新测量。
- 重复以上步骤,直到达到目标或优化的性价比不再合理。
Guardrails
注意事项
- Do not claim an optimization without before/after evidence.
- Be careful not to optimize the wrong metric.
- Watch for regressions in correctness, reliability, maintainability, and security.
- Prefer changes that are measurable, explainable, and reversible.
- 没有前后对比数据,不要声称优化有效。
- 注意不要优化错误的指标。
- 警惕正确性、可靠性、可维护性和安全性方面的退化。
- 优先选择可测量、可解释且可回滚的修改。