不靠猜测，测出慢在哪里

目标

在性能问题中，最昂贵的错误是修复错误的地方。用眼睛读懂 如果选择“这里好像很慢”，通常会偏离主题。

在这里确认库存、阅读、修改、重新阅读是否减少了。

材料

/opt/lab/perf/slowapp.py   느린 곳이 어디인지 눈으로는 안 보이는 프로그램
/opt/lab/perf/iowork.py    같은 일을 순차·스레드·프로세스로 해 보는 프로그램

首先导入到工作目录。

mkdir -p /root/perf && cp /opt/lab/perf/* /root/perf/ && cd /root/perf

要留下的东西

01-time.txt      real·user·sys
02-tottime.txt   자체 시간 순
03-cumtime.txt   누적 시간 순
04-fix.txt       고치기 전과 후
05-gil.txt       CPU 바운드: 순차·스레드·프로세스
06-wait.txt      기다리는 일: 순차·스레드
07-notes.md      왜 그런지

三个数字告诉我们什么

slowapp.py的time重新输入real · user · sys01-time.txt留下，写一句话说明real大于user+sys是什么意思。

{ time python3 slowapp.py ; } 2> 01-time.txt

user是我的代码使用CPU的时间，sys是内核代替我花的时间，real这是用银色手表测定的时间。

real比user+sys大的话，就等了那么多差别的。CPU再快也无法减少那个部分。

第一行不是要改正的地方

cProfile以自身时间（tottime）顺序排列，将上列的行02-tottime.txt留下来，写下为什么最长的线不是要修的地方。

python3 -m cProfile -s tottime slowapp.py 2>&1 | head -12

最上面是time.sleep应该可以。但是那是不使用CPU等待的时间，所以不能通过快速编写代码来减少。

可以修复的东西在下面。

自己花多长时间，别人花多长时间呼唤

这次按照累积时间（cumtime）顺序返回03-cumtime.txt请留在这里。enrich写下tottime接近0，cumtime大的意思是什么。

python3 -m cProfile -s cumtime slowapp.py 2>&1 | head -12

tottime是那个函数中直接使用的时间，cumtime是那个函数呼叫的加上的时间。

tottime是0，但cumtime很大的话，这个函数本身没有错误，叫谁才是问题。需要修改的地方是被调用的方。

修好后再量一次

slowapp.py的fastapp.py复制到罗中只修改慢的部分，修改前后的时间04-fix.txt请留下。也写下为什么这么慢的一句话。

parse把字符串一个字一个字地+=相连。字符串是不变的值，所以每次相连都会把新字符串整块组成。按长度平方排列。

''.join(...)可以用列表综合来一次性制作就可以了。

修改后用**同样的方法重新调整。**不调整的话就无法知道是否修改了。

即使增加线程也不会变快。

iowork.py cpu按顺序、线程、进程三个方向进行。05-gil.txt留下，写下为什么不能用线程快速处理。

for how in seq thread proc; do python3 iowork.py cpu $how; done

线程几乎保持不变，只有流程会变快。

Python有一次只能让一个线程执行比特币的锁定（GIL）。只计算的事情不会释放那个锁定，所以即使增加线程也相当于按顺序运行。进程是独立的解释器，那个锁定也是独立的。

同样的工具反向运行

这次iowork.py wait用顺序·线程返回06-wait.txt留下，请写下为什么这边通过线程更快。

for how in seq thread; do python3 iowork.py wait $how; done

**等待期间会释放该锁定。**这样其他线程就可以在期间工作了。

所以对于“线程快吗”的问题没有答案。分成了“等待什么”：等待网络、磁盘、数据库的话线程会赢，等待计算的话进程会赢。

给下次读的人

从这里看到的中选择至少3个以上07-notes.md请整理一下。不要写做了什么，而是写为什么那样。

请想象几个月后遇到性能问题的自己正在阅读。“旋转了cProfile”没有帮助，但“tottime很大，如果线程是sleep，那不是CPU问题——可以修复的是在它下面”是有帮助的。