Performance Optimization History¶
重要性:⭐⭐⭐⭐ 目标读者:性能工程师 / 优化者 关联:analysis/performance-history.md
1. 概览¶
本文档深入分析 Claude Code 的性能优化历史。
5 阶段: - V1 单文件 - V2 模块化 - V3 React/Ink - V4 高级优化 - V5 当前
2. V1: 单文件时代(推测 ~2024)¶
特征: - 1 个 main.js - 几百行 - 同步阻塞
性能: - 启动 < 100ms(推测) - 内存 < 30MB
痛点: - 难维护 - 不能扩展
3. V2: 模块化(推测 ~2024-Q3)¶
变化: - 拆 utils / services / tools - 引入 TS - 引入 React/Ink
性能: - 启动 ~300ms(增加 import 时间) - 内存 ~50MB
优化: - 移除循环依赖 - 引入 memoize
4. V3: 高级优化(推测 ~2024-Q4)¶
变化: - 加 MCP 集成 - 加 Plugin 系统 - 加 50+ tools - 加 state/AppStateStore
性能压力: - 启动 ~500ms - 内存 ~80MB
优化: - feature gate + lazy require - memoize 三变体 - 30+ profileCheckpoint
5. V4: 启动优化(推测 ~2025-Q1)¶
关键变化: - 顶部并行预取(startMdmRawRead + startKeychainPrefetch) - preAction 集中 init - print 模式 fast-path - 首屏后预取
性能: - 启动 ~500ms(稳定) - 内存 ~100MB
关键 insight: - 与 import 并行 ~200ms 节省 - print 早返回 ~50-100ms 节省
6. V5: 当前(2025+)¶
特征: - 25+ bash validator - 4-slot LRU - 50ms bash parse timeout - speculative LLM classifier
性能: - 启动 ~500ms - TTFT ~1-1.5s - 内存基础 ~100MB
7. 优化时间线¶
V1 (2024-Q1): 单文件
→ 启动 < 100ms (功能少)
V2 (2024-Q3): 模块化
→ 启动 ~300ms (import 时间)
→ 优化: memoize, 移除循环
V3 (2024-Q4): MCP + Plugin
→ 启动 ~500ms (更多模块)
→ 优化: feature gate + lazy require
V4 (2025-Q1): 启动优化
→ 启动 ~500ms (与 import 并行)
→ 优化: 顶部预取, preAction, print fast-path
V5 (2025+): 高级优化
→ 启动 ~500ms (稳定)
→ 优化: 25+ validator, 4-slot LRU, speculative LLM
5 阶段。
8. 8 大优化技术详解¶
8.1 顶部并行预取(~200ms)¶
节省 200ms。
8.2 preAction 集中 init¶
program.hook('preAction', async () => {
await Promise.all([ensureMdmSettingsLoaded(), ensureKeychainPrefetchCompleted()])
await init()
await initSinks()
runMigrations()
void loadRemoteManagedSettings()
void loadPolicyLimits()
})
6 步集中。
8.3 print 模式 fast-path¶
if (isPrintMode && !isCcUrl) {
await program.parseAsync(process.argv)
return program // 不注册 20+ subcommand
}
节省 50-100ms。
8.4 feature gate + lazy require¶
商业版砍 25000+ 行。
8.5 memoize 三变体¶
3 变体。
8.6 30+ profileCheckpoint¶
可观测性。
8.7 4-slot LRU (Yoga)¶
80% 命中。
8.8 speculative LLM¶
UX 黑魔法。
9. 启动时间分解¶
| 阶段 | 耗时 | 优化 |
|---|---|---|
| Bun 启动 | ~50ms | - |
| 模块求值 | ~100-200ms | lazy require |
| 顶部副作用 | 与 import 并行 | startMdmRawRead |
| main() | ~50ms | - |
| preAction | ~50-100ms | await parallel |
| run() | ~50ms | - |
| 第一个 render | ~50ms | - |
| 后台预取 | 不阻塞 | void |
总计 ~500ms。
10. TTFT 分解¶
用户提交 prompt
↓ 0ms
getAttachments 1s timeout
↓ 100ms (typical)
调 Claude API
↓ 500-2000ms (TTFT)
收到首个 chunk
TTFT ~1-1.5s。
10.1 优化 1: attachment 并行¶
const results = await Promise.all([
maybe('at_mentioned_files', () => ...),
maybe('mcp_resources', () => ...),
// ...
])
并行。
10.2 优化 2: prompt cache¶
cache 节省 90%。
10.3 优化 3: streaming¶
streaming。
10.4 优化 4: 投机 classifier¶
黑魔法。
11. 内存优化¶
11.1 基础¶
- 50-100MB 启动
- 200-500MB 大 session
- 5-20MB/plugin
- 5-10MB/MCP
11.2 优化 1: Plugin cache¶
节省。
11.3 优化 2: SessionStorage 增量¶
增量。
11.4 优化 3: Compact¶
减少。
12. 5 个未来优化方向¶
12.1 main.tsx 拆分¶
拆。
12.2 预连接¶
预连接。
12.3 Snapshot 启动¶
Snapshot。
12.4 Worker 卸载¶
Worker。
12.5 增量布局¶
增量。
13. 5 个监测工具¶
13.1 profileReport¶
启动报告。
13.2 getYogaCounters¶
Yoga 监控。
13.3 useFpsMetrics¶
FPS 监控。
13.4 Event Loop Stall¶
主线程监控。
13.5 Statsig¶
远程。
14. 5 个关键 insight¶
14.1 启动是用户体验¶
500ms 是用户感知阈值。
14.2 并行 > 串行¶
顶部预取是关键。
14.3 缓存层 6 类¶
memoize / LRU / TTL / session / content hash。
14.4 可观测性前提¶
30+ 埋点。
14.5 渐进式优化¶
不是重写。
15. 数字总览¶
| 数字 | 值 |
|---|---|
| 启动 | ~500ms |
| TTFT | ~1-1.5s |
| 内存 | 50-100MB 基础 |
| 30+ | profileCheckpoint 埋点 |
| 25+ | bash validator |
| 4 | memoize 变体 |
| 5 类 | 缓存策略 |
| 8 大 | React 优化 |
| 6 种 | 启动模式 |
| ~25000 | DCE 节省行 |
10 数字。
16. 总结¶
Performance Optimization History = 5 阶段 + 8 大技术。
核心: - 启动 500ms 渐进 - 30+ 埋点 - 8 大优化 - 5 阶段演进
下一步: - 看 performance-history.md - 实施监测 - 持续优化