感觉你写的对啊

不是青轴就行了吧 :D
我会小心不吵到别人，现在用的黑轴，中午休息时也放心用

觉得没说清楚，补充一些

情景是，有一批文本，先用算法预标注，再给人工改标注。人工需要知道每条文本的来源和种类，这就要把这些信息和文本拼在一起，最后再转化回原始文本。加信息和转化回原文本，都有随着文本一起改动标签的需求。

最近这个项目枯萎了。工具到这个程度，它适用的范围也不能小规模论证了。所以想请 nlp 专业人士和爱好者们一起打磨这个想法。

把 linux 当作开发机免不了经常折腾。
就是在这种折腾当中，了解关键概念、原理、实现，最后解决问题，得到提升。

服务器一旦上线，倒不用像开发机这样经常折腾，因为服务器以稳定服务为第一要务，软件升个级都是需要多人配合、尝试的“大事”。

学习、练习的话，用虚拟机或者 docker 会方便一点。

如果只想省事，不如直接用 windows。

因为程序和工程上这些概念，英文一看就明白了，中文看了还得反应一会。而且同一个词，每个软件的翻译还不一定一样。

都挂了还同步什么。。
我怎么觉得他是想问挂了以后怎么恢复？

git 完全可以

多谢 pympler 这个工具推荐
我搜 python memory profile and debug，为什么没搜出这个工具呢，只看到了 line profiler，heapy 啥的

这样搞是一个思路了，很笨的一个思路呵呵，很慢，跑十几分钟才跑出十分之一：

```python
from pympler.asizeof import asizeof

h0 = hp.heap()

ds = h0[0]

# 获取"根"dict set
root_ds = (ds - ds.referrers).byid

# 看一看每个“根 dict ”的 recursive size
sizes = []
for i in range(len(root_ds)):
info = i, asizeof(root_ds[i])
sizes.append(info)

# check size
```

我感觉这个测量是靠谱的
greenlet 虽然把 call stack 弄得“支离破碎”，但很有可能，在每个时刻对解释器来说是能够还原出当前线程的信息的。
所以说，图最右侧的是真正的 io 时间。这段时间内，gevent 发现，所有协程都阻塞住，没有任何一个能够继续往下走。
你那张图，如果用 top 观测 cpu rate，应该在 20%左右。当然也有可能不止，因为图上的 idle 也有可能在 run cpu，只是 pyflame 没法测它。


当然我说的不一定对。python 实现，greenlet，pyflame 的机制还要了解更多才知道。

@monsterxx03 我没有 idle，但是 wait 很长，像你的图右侧一样。不知中间的那部分是否有参考性。
没有 google 到什么解释。大概只能从二者的原理入手来理解了吧。

@monsterxx03 我在火焰图上没看到 idle. top 显示的 idle 还是比较高的,因为我的程序主要慢在,io 太多,且 io 和 cpu 是串行的,cpu 在等待 io.所以 cpu 利用率很低.

所以我打算引入 gevent 了.用 coroutine 先把 cpu 占满.
引入 gevent 之后,pyflame 还能用吗?我还没有试呢.
按照我的理解,greenlet 的实现,是自己维护了以及 process 运行的必要环境,比如各种堆栈;switch 时在自己维护的环境和真实环境中相互 copy.所以 pyflame 应当还是可以 work 的.这个理解对吗?

@eclipselu @monsterxx03 我试了 pyflame
如果 all 的值是 40000,某一个函数 f 的值是 30000,意思就是,在 40000 次抽样当中,有 30000 次,调用栈里都包含函数 f 的 frame.所以整个调用函数 f 的时间,其实占用了整体时间的 75%.
如果有多个 thread,由于 GIL 的关系,同一时刻只有一个 thread 在运行.所以这个对时间的估计依然成立.
我的理解对吗?

话说回复不能贴图吗?...

@monsterxx03 看起来很牛哦，我先了解一下

@zhangmiaoCHN cpu 部分也可能有比较耗 cpu 的部分，然而网络请求也很多很频繁。最关键的，目前都是串行的，等 io 结果出来再做事。我们的考虑是，如果耗 cpu 的任务能够不用等待 io （我们这个场景下逻辑上是可行的），会节省许多时间。
所以想测量一下 cpu 时间和 io 时间，看看二者的比例到底如何。

get 也可以有 body 的.
读 elasticsearch 的文档时才意识到这一点.
elasticsearch 的许多 api,都是 get 带 body 这样用的.

4 如果是云环境,比如 aws 或者阿里云,有创建磁盘 image 的功能,直接把这些脚本放到 root image 里.

测试时,有时会出现有两个正确答案,比如前两个按钮都是"yo"
我选了第二个,结果第一个才是正确的.