Profiling

性能优化思路：从测量到代码的五层递进方法论 优化不靠直觉，靠数据。这篇文章是我在给 Hical 做性能优化时沉淀下来的一套方法论：从"用 profiler 找到真正的瓶颈"，到架构选型、系统间交互、数据结构、再到最后的代码级微优化，一共五层，层层递进。每一层都有对应的工具、实战案例和"什么时候别优化"的提醒。看完你会发现，大部分性能问题根本轮不到写代码，先想清楚在哪一层出手，比埋头优化重要得多。 目录 第零层：测量——找到真正的瓶颈 性能优化五层模型 架构级性能优化 （子）系统间性能优化 数据结构与算法性能优化 代码级性能优化 性能回归检测：优化完了怎么守住 第零层：测量——找到真正的瓶颈 优化不是凭直觉猜，是数据驱动的工程决策。没有 profiling 数据就动手，相当于在黑屋子里开枪——打中算运气，打不中浪费子弹。我在 Hical 上踩过的第一个坑就是猜错了方向：光凭代码感觉觉得是协程帧太多，结果 perf 一跑，14.5% 的 CPU 其实耗在调度器上。所以，先量，再动。 工具链：每种工具回答一个问题 工具 回答什么问题 Hical 实战 perf record + 火焰图 CPU 时间花在哪了 perf record -g -F 99 → docker 内 10s wrk strace -c 系统调用频次和时间占比 epoll_ctl 31351 次占 25.92% GTest 性能用例 函数级性能断言 test_router_perf.cpp，100K 次 dispatch 计时 wrk / wrk2 端到端吞吐和延迟分布 wrk -c100 -t4 -d30s heaptrack / valgrind massif 内存分配热点 找意外的大分配 perf stat -d IPC、分支预测率、cache miss 看整体健康度 火焰图怎么看 拿 Hical 实际火焰图数据来说（docker 内 wrk -c10000 -d10s，perf record -g -F 99）： ...

Lua 性能分析工具实战 适合读者：想在项目中定位 Lua 性能瓶颈、用数据说话的开发者 本文以 Lua 5.3/5.4 为基础，结合游戏服务器实际场景 第一章：为什么要做性能分析？ 1.1 一个常见的困境 你写了一堆"Lua 性能优化技巧"文档，告诉你用 local、少创建 Table、重用对象……但是： 1 2 3 4 问题 1：线上服务器慢，但到底是 C++ 慢还是 Lua 慢？ 问题 2：几个队友都说自己的代码"没问题"，如何客观地找到最慢的？ 问题 3：优化后怎么"证明"确实变快了？ 问题 4：上线前怎么防止新代码引入性能回退？ 答案：不要靠猜，用工具说话。 1.2 性能分析金字塔 1 2 3 4 5 6 7 8 9 10 11 ┌──────────┐ │ 线上监控 │ ← 最慢但最真实 ├──────────┤ │ 压测场景 │ ← 模拟真实负载 ├──────────┤ │ 单元分析 │ ← 分析单个函数/模块 ├──────────┤ │ CPU Prof │ ← 采样/插桩分析 ├──────────┤ │ 代码审查 │ ← 最便宜但最不准 └──────────┘ 本文从下往上，带你把每一层都跑通。 ...