最近把项目里那个"感觉有点慢"的模块翻出来收拾。之前一直靠在关键函数里撒 print 看耗时，又脏又不准。后来挂了个 profiler，业务代码一行没动，直接把每个函数耗时占比画出来，谁是拖油瓶一眼清楚。
最爽的是火焰图。最烫的那条调用栈从上往下摊开，方块越长越该挨刀，优化从此有了靶子，不用凭直觉瞎猜。以前总说"这里应该能再快点"，现在拿数据说话，省得跟人争。
本地跑一遍，CI 里也接上，把性能当能追踪的指标留着。哪天谁再说卡，拉两条曲线一比就知道谁退化了，而不是等用户上线骂街才反应过来。现在谁再扯"感觉慢"，我直接把图甩过去。
补个坑：你 CI 里接的应该是 on-CPU 火焰图吧。多数 profiler 默认只采 CPU 时间，IO 等待、锁、网络这些 off-CPU 时间采不到。代码卡在等数据库或第三方接口时，图看着平平的，容易误判成没瓶颈。试试 wall-time 火焰图，py-spy 加 --wall 或 offcputime.py，把"等"的时间也摊开。我之前也是盯着 CPU 图找半天，换成 wall
火焰图比 print 直观太多了。不过得确认本地和 CI 跑的是同一份代表性负载，负载不对，图上最烫的那条未必是线上真瓶颈，优化半天可能白挨刀。
火焰图那句"越长越该挨刀"得补个前提。火焰图是按采样占比画热的，热不等于该砍。最烫的函数可能本身就是该干的活，真正问题是它被上层无意义地调了几万次，这时候该动的是 caller，不是那个长条。还有更隐蔽的一类：CPU 火焰图只采到在跑的时间，I/O 等待、锁竞争、context switch 这些 off-CPU 时间是看不见的。模块要是 I/O bound，你对着一张平平的图干瞪眼，其实瓶颈在等数据库。这种得上 off-CPU 分析或者看 wall-time 火焰图。
CI 接性能门禁这个做法很实在，但共享 runner 上的绝对耗时波动很大，隔壁 job 抢 CPU、被 throttle 一下数字就能飘 20%。直接拿绝对值比大小，要么天天误报要么慢慢钝化。稳妥点是设方差阈值加统计比较，而且 workload 尽量贴近真实流量，别用 toy benchmark。CI 里"零退化"不代表线上不卡，这点最容易给假安全感。
你用的哪种 profiler，sampling 还是 instrumentation？我偏向 attach 式 sampling，线上直接挂，零改动就是它最大的卖点。
我年轻时也爱凭手感瞎改，后来才信了量出来的数。火焰图是好东西，可最长那块不一定最该动刀，有些慢长在骨头里，削了反而散架。
前排 你这把图甩过去的操作太帅了 我平时跟人争起来全靠嘴皮子 要是有个profiler量一量谁磨蹭谁背锅就好了 哈哈哈 尤其最后"等用户骂街才反应"那段 真实得想哭 我交稿也老这样 拖到编辑来催才动弹
把图甩过去这招真解气哈哈 我就烦凭感觉瞎争 拿数据说话才踏实
火焰图那条有个坑得提醒你：它默认量的是 on-CPU 时间，只看得见真正在 CPU 上跑的那部分。你那模块要是慢在等数据库、等锁、等网络，火焰图会一片清凉，时间其实全耗在 off-CPU 上了。
顺手把 off-CPU / wall-clock 的图也挂上，靶子才算画全。另外 CI 里比曲线记得取多次跑的中位数，机器负载一抖，单次数字能骗你，别把噪声当退化。
我之前也是往关键函数里塞 print 看耗时，后来挂上 profiler 就回不去了，你说的有靶子那种感觉特别准。
补一个 CI 的坑：runner 大多是共享低配机，旁边还跑着别人的任务，CPU 被抢很正常。同段代码今天 1.2s 明天 1.8s 都常见。所以别在 CI 设绝对耗时阈值，设相对基线更稳：跟上一个稳定 commit 比，涨了 X% 才报警。曲线才有可比性，不然天天误报，看久了谁都不瞅。
本地和 CI 数字本来就会差一截，别拿它俩互相印证，各当各的参照系就行。
甩图怼"感觉慢"这习惯我挺服，比空口争强十倍。
凭手感过日子的人，最怕的就是那种"说不清哪里不对"。你这篇把那种模糊的焦虑换成了把能摊开看的尺，读着竟有种松口气的轻。
我们争起来的时候，九成卡在一个"我觉得"上。谁都觉得自己那点感觉最准，可感觉偏偏是最靠不住的证人。你挂上 profiler，等于给那段说不清的事请了个不说话的裁判——它不站队，只把最烫的那条栈从上往下摊开，方块越长，越该挨那一刀。从前要争半天的，如今一甩图过去，比一万句"我早说过"都体面。
最让我心动的是你把曲线留在 CI 里这件事，像给时间留了底稿。人太容易好了伤疤忘了疼，等用户骂街才惊觉——生活里那些慢下来的关系，往往也是凉透了才回头想，却早忘了是从哪天开始退化的。有张图挂着，至少看得见下坡的路。有一说一
不过想补一句：尺能量长短，量不出"为什么这条栈偏偏最长"。有时候方块最长，不是它该挨刀，是它替上头的烂摊子扛了活。图甩出去之前，或许还得陪它走一段，看清底下压着什么。
怎么说呢nope_v 前阵子要是看见你这招，大概也要说声服气。
我年轻那阵子也犯过这毛病，模块慢了就凭直觉在循环里抠，折腾半宿，最后发现真正拖后腿的是个不起眼的字符串拼接。你要是早些年跟我说"先量再改"，我准嫌啰嗦。
火焰图好就好在它不跟你争，方块一摊开谁该挨刀清清楚楚。不过我多嘴补一句：那图到底是在什么情形下量出来的…，这事儿挺要紧。本地那套负载跟线上真来流量时未必一个样，有时候"感觉卡"偏偏出在图里没摊开的那条冷路径上。哪天有人说还是慢，把图甩过去固然痛快，可真要服人，最好连当时的测量条件一并说清楚，免得空对空地抬杠。
以前跟人争"哪里慢"也是各凭感觉，谁也说服不了谁，你这招甩图过去确实利落。会好的不过小火苗也有坑，最烫的那条未必最该动…，线上压根跑不到几回的话，优化半天也是白费劲~