菜单
当用户面临性能优化、架构选型或容量规划时，通过量化方法避免感性决策和过早优化。 适用场景：需要评估加速上限、拆解 CPU 时间构成、建立负载-性能模型、对比架构方案时。 不适用于：纯信息查询（某工具怎么用）、日常琐碎选择（选哪个编辑器主题）、或已经明确是代码 bug 的调试场景。 关键 trigger：用户提到"优化""加速""瓶颈""扩展性""选型"并伴随多个方案比较或不确定是否值得投入时。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | quantitative-performance-analysis |
| description | 当用户面临性能优化、架构选型或容量规划时，通过量化方法避免感性决策和过早优化。 适用场景：需要评估加速上限、拆解 CPU 时间构成、建立负载-性能模型、对比架构方案时。 不适用于：纯信息查询（某工具怎么用）、日常琐碎选择（选哪个编辑器主题）、或已经明确是代码 bug 的调试场景。 关键 trigger：用户提到"优化""加速""瓶颈""扩展性""选型"并伴随多个方案比较或不确定是否值得投入时。 |
| source_book | 《CS Core Thinking Meta-Framework》Hennessy & Patterson, Kleppmann et al. |
| source_chapter | CAQA Ch.1.8–1.9 / DDIA Ch.1 |
| tags | ["quantitative-analysis","performance-engineering","speedup-bounds","load-modeling"] |
| related_skills | [] |
"CPU time = Instruction count × Clock cycles per instruction × Clock cycle time. As this formula demonstrates, processor performance is dependent upon three characteristics: clock cycle (or rate), clock cycles per instruction, and instruction count." / "Amdahl's Law states that the performance improvement to be gained from using some faster mode of execution is limited by the fraction of the time the faster mode can be used." — Hennessy & Patterson, CAQA Chapter 1.8–1.9
"It is meaningless to say 'X is scalable' or 'Y doesn't scale.' Rather, discussing scalability means considering questions such as 'If the system grows in a particular way, what are our options for coping with the growth?" / "High percentiles of response times, also known as tail latencies, are important because they directly affect users' experience of the service." — Kleppmann, DDIA Chapter 1
这个框架提供三条相互补充的量化路径，用于把"感觉慢"转化为可决策的数字：
加速上限评估（Amdahl 定律）：任何局部优化对整体性能的贡献都有硬上限。先测量被优化部分在总时间中的真实占比，再计算即使该部分被无限加速，整体能快多少。若上限低于业务目标，就应放弃单点优化，转向架构重构。
CPU 时间三元拆解（CPU Time = IC × CPI × Cycle Time）：把执行时间拆成指令数（IC）、每条指令周期数（CPI）、时钟周期时间（T）。通过性能计数器定位瓶颈项：IC 高 → 改算法或编译器；CPI 高 → 改流水线、缓存、分支预测；T 大 → 换更高频率或更先进工艺。
负载-性能建模（DDIA）：扩展性讨论必须以量化负载为前提。用具体参数（请求/秒、读写比、fan-out、数据量）描述负载，用性能指标（吞吐量、中位数延迟、尾部延迟 p95/p99/p999）评估系统行为。当负载增长时，必须回答两个问题：a) 资源不变时性能如何变化？b) 要保持性能不变需要增加多少资源？
核心原则：没有测量就没有优化；优先投资常见情况；不要对非瓶颈项过度投入。
locality-driven-optimization 的区别: 本 skill 聚焦"量化评估和决策框架"（Amdahl、CPU Time、负载-性能模型），而局部性 skill 聚焦"如何利用时间/空间局部性指导具体优化"。concurrency-and-fault-tolerance 的区别: 本 skill 讨论性能数字和加速上限，后者讨论并行引入的正确性风险与故障模式。data-system-reliability-assessment 的区别: 本 skill 的 RSM 维度主要聚焦 Scalability 的量化，后者覆盖 Reliability + Maintainability 的更广泛评估。当 skill 被激活后，agent 应按以下步骤执行:
明确优化/选型目标与约束
建立基线测量（Baseline）
应用三元拆解或 Amdahl 评估
评估各方案的边际收益与成本
给出可执行的决策建议与下一步动作
标注边界警告（Boundary Check）
在没有测量的情况下进行优化（ce30）："Premature optimization is the root of all evil. You cannot improve what you do not measure." 工程师凭直觉对自认为的瓶颈进行优化，投入大量精力重构代码或引入复杂技术，但实际瓶颈位于别处，整体性能几乎没有改善。Amdahl 定律指出：对非瓶颈部分的优化无论多么成功，对整体加速比的贡献都极其有限。
Amdahl 定律不适用（ce03）：设计者忽略串行部分的比例，盲目增加核心数或处理器数量，导致加速比远低于预期，投资回报率极差。Amdahl 定律指出加速比上限受限于不可并行化的串行比例。即使并行部分无限扩展，总加速比也受 1/(1-p) 的硬边界约束。
单纯提高时钟频率忽视功耗墙（ce04）：通过提高电压和频率榨取性能，导致动态功耗按立方增长（P = C·V²·f），芯片散热不可持续，最终触发热节流（thermal throttling），实际性能反而下降。这是 2000 年代中期单核频率竞赛终结的根本原因。
流水线深度可以无限增加（ce02）：过度细分流水线级数导致分支预测失败和缓存未命中的惩罚代价呈指数级放大，实际 CPI 恶化，功耗也急剧上升。深层流水线的假设（无冒险、完美预测）在真实程序中不成立。
缓存越大越好（ce01）：盲目增大缓存容量导致命中时间（hit time）显著增加，反而降低处理器时钟频率或增加流水线级数，最终整体性能下降。缓存访问延迟与容量呈非线性增长，当容量超过工作集后，边际命中率收益递减。
当用户需要在 API、数据库 schema、软件架构中设计可长期演化的抽象边界时激活。 典型场景：接口与实现耦合导致重构困难、schema 变更引发下游崩溃、需要评估版本化策略、设计 DSL 或分层架构时。 不适用于：纯语法问题、一次性脚本、已完全封闭的第三方系统黑盒调用。
当用户设计文件系统、数据库存储引擎、分布式存储或 RAID 阵列时，需要在崩溃恢复与持久化策略之间做量化权衡。触发信号包括：WAL/journaling 模式选择、ARIES Redo/Undo、LFS 与 COW 对比、fsync 顺序、metadata journaling、断电一致性、small-write penalty 等。 不适用于：纯查询优化（加索引/改写 SQL）、无持久化层的纯网络架构、日常应用层缓存选型。
当用户讨论任何与计算机科学核心思维相关的系统设计、性能优化、并发控制、网络协议、数据存储、持久化、形式化验证、抽象设计、调度策略、查询优化或数据结构选型时，**必须立即调用本 skill**，不要试图直接跳到底层 skills。 本 skill 是 18 个 CS core thinking skills 的唯一入口，负责在用户意图与具体技能链之间做路由，防止遗漏前置分析（如跳过 quantitative-performance-analysis）或错误匹配领域。 典型触发场景（包括但不限于）：系统架构设计评审、性能瓶颈根因分析、缓存/存储策略选型、数据库事务隔离级别选择、分布式锁与共识协议设计、TCP/丢包/拥塞/滑动窗口问题、概率数据结构（Bloom filter/Treap）选型、算法正确性证明与不变量推导、操作系统虚拟化与 CPU/内存调度、抽象边界与接口演化、DSL/解释器设计。 边界模糊场景也必须触发：如"分布式数据库查询慢"可能同时涉及查询优化和网络分区，此时 router 会判断主诉并给出调用链；"Redis 缓存穿透"可能涉及概率数据结构或可靠性评估，同样先走 router。 不适用于：纯前端 UI 设计、日常运维操作（如重启服务/查日志）、无上下文的单一算法题求解。
当用户面临数据库/存储选型、schema 设计、查询语言选择或多模型共存架构决策时激活。 典型信号：讨论关系型 vs 文档型 vs 图数据库选型；提到 " impedance mismatch "、"schema 灵活"、"多对多关系"、"图遍历"、"Cypher/SPARQL"；需要为不同查询模式选择存储引擎或列存方案。 不适用于：纯 SQL 语法调试、单一数据库的运维问题、与数据模型无关的分布式一致性讨论。
用于后端/数据系统架构评审时，对可靠性、可扩展性、可维护性（RSM）进行系统化风险评估与改进建议。 当用户讨论系统架构设计、容量规划、SLA/SLO 制定、故障场景分析、容灾策略、性能优化或技术选型时激活。 不适用于：纯代码实现细节、前端 UI 设计、单一算法题求解、日常运维操作（如重启服务、查日志）。
当用户需要设计或分析领域专用语言（DSL）、构建解释器/编译器、利用高阶过程消除重复模式、或理解"程序即数据"的元语言抽象时激活。 典型信号：讨论 eval/apply 循环、环境模型、惰性求值、闭包性质、宏系统、语法树变换、寄存器机器模型、SICP 第4章相关内容。 不适用于：纯语言语法学习、框架 API 调用、不涉及抽象控制的日常编码问题。